On 6/5/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> I can modify it to catch it pretty easily, just walk back a few vuses
> if the current set of vuses is defined by something that does not
> actually touch our offset.
This sounds like what I am trying to do in ccp...
> >
> > I am not sure I understand. The new patch uses the infrastructure of
> > the propagator and I do not see an indication in the dumps for vdefs
> > update after the lattice value is changed:
> >
> > 19930
> > 19931 Visiting statement:
> > 19932 D.61410.first = i0_62;
> > 19933
> > 19934 Lattice value changed to CONSTANT 0. Adding SSA edges to
worklist.
> > 19935
> >
> > Thanks again fo your help,
> > Revital
>
> So uh, how do you expect the propagator to notice when the used
> variables have changed if the things the vdefs produced by
> D.61410.first are not marked as change (so that the immediate uses of
> it get processed).
>
> You will need to add this if it is not there already.
>
>
> Normally, the propagator says "oh, the lattice value of D_64 changed,
> let me mark all it's immediate uses for reprocessing". The only thing
> that links memory defs to memory uses is the vdef/vuses, so you will
> have to be able to process and mark those
I thought the engine suppose to take care of that. I do not understand
why this case is different from other cases where we propagate for
vdefs...
The engine only knew how to propagate cases that always make the same
set of vdef/vuses, so it was safe to only tell it to use the first
vdef.
/* Note that for propagation purposes, we are only interested in
visiting statements that load the exact same memory reference
stored here. Those statements will have the exact same list
of virtual uses, so it is enough to set the output of this
statement to be its first virtual definition. */
You are changing this, AFAIK, so you will need to make it handle
multiple output values.
Thanks again,
Revital
