> > 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... > > The final propagator replaces the right operand (D.65705_98) in the > > following if condition with a constant zero which causes the program to be > > aborted as i0_62 is not always zero: > > > > # i0_62 = PHI <i0_5(29), 0(3)> > > <L139>:; > > D.61410.first = i0_62; > > ... > > D.65705_98 = D.61410.first; > > - if (D.65704_96 >= 0) > > + if (D.65704_96 >= D.65705_98) > > goto <bb 11>; > > else > > goto <bb 14>; > > > > Tracing the execution of the propagator it seems that the if statement > > is first been propogated with zero after simulating the execution; but not > > updated after the lattice value of the variables it depends on changed. > > Does your store CPP properly say the vdefs have changed when a > statement's lattice value changes? 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
