This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa, RFC] new, very experimental ssa-vn
Hi,
On Monday 05 January 2004 10:41, Pop Sébastian wrote:
> Hi Steven,
>
> On Mon, Jan 05, 2004 at 02:24:23AM +0100, Steven Bosscher wrote:
> > I still have a bug that I don't quite understand yet. Consider:
> >
> > foo (void)
> > {
> > int i, j;
> >
> > for (i = 0; i < 10; i++)
> > for (j = 0; j < 10; j++)
> > { }
> > }
> >
> > We would find that i and j are congruent, but clearly they are
> > independent. I am not sure if this is a bug in my implementation, or just
> > a mess-up in the removal algorithm. Morgan gets it all wrong, and
> > Simpson's thesis doesn't help much either. Looking at my dumps, I seem
> > to be doing the Right Thing, but it gives a useless result. Worked
> > around by requiring that PHIs can only be congruent if they are in the
> > same BB (by hashing bb_for_stmt), I think it does not pessimize the
> > algorithm (at least, not too much ;-), all that happens is that we don't
> > find congruences that would not give opportunities for redundancy
> > elimination anyway.
>
> I would check the loop_num (loop_of_stmt (phi-node)) instead of
> bb_for_stmt (phi-node). If the loops differ, then the considered
> evolutions belong to two different dimensions. In terms of chains of
> recurrences, the above example is translated to:
> i -> {0, +, 1}_loop1
> j -> {0, +, 1}_loop2
> Since (loop1 != loop2) you don't have the same evolution for i and j.
>
> Could you try the following condition:
>
> if (loop_num (loop_of_stmt (phi1)) == loop_num (loop_of_stmt (phi2)))
> /* then "valid value representative for `phi1' is `phi2'" */
That would not work since there would still be optimistic value
representatives that were found under the assumption that i and j are
congruent. The algorithm has to figure out in its optimistic phase that
they are not congruent at all.
Also I think it is a bad idea to make this pass depend on the availability
of loop information.
Gr.
Steven