Re: Help in understanding ccp propagator

["Daniel Berlin" <dberlin at dberlin dot org>]

On 6/4/07, Revital1 Eres <ERES@il.ibm.com> wrote:
> > > I will greatly appreciate any suggestions regarding the following
> > > problem I have with the ccp propagator. I am testing the new store
> > > ccp patch which propagates constants by walking the virtual use-def
> > > chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
> > > encountered the following problem while testing tree_join.cc file which
> > > is under libstdc++-v3 testsuite:
> >
> >
> > BTW, a lot of these will be caught with the new VN i posted, whicih
> > should be reviewed and go in soon.
>
> Thanks, should it handle cases like the one in the following example -
> http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00081.txt?  I tried it with
> the VN patch but it seems to not caught it...

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

>