> 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...

Thanks again,
Revital

Reply via email to