This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: More PRE problems
On Mon, Nov 17, 2003 at 08:08:29AM -0700, law@redhat.com wrote:
> In message <Pine.LNX.4.56.0311141549140.10454@dberlin.org>, Daniel Berlin write
> s:
> >
> >
> >On Fri, 14 Nov 2003, Daniel Berlin wrote:
> >
> >> >
> >> > What's critical here is the PHI node in block 10 for pretmp.137_91 and th
> >e use
> >> > of T.104_74 in that PHI node:
> >> >
> >> > # BLOCK 10
> >> > # PRED: 16 13 9 (fallthru,exec)
> >> > # i_5 = PHI <0(16), i_72(9), 0(13)>;
> >> > # pretmp.137_91 = PHI <T.104_74(9), pretmp.137_92(13), T.104_19(16)>;
> >> >
> >> > T.104_74 is defined in block 11 and there is no path from block 11 to
> >> > the use in block 10.
> >>
> >> Yeah, i'm not quite sure whose ass we pulled this argument out of.
> >
> >
> >Okay, i see what happens.
> >
> >The first argument of the ephi ends up being the ephi itself.
> >
> >IE it really should be
> >pretmp.137_91 = PHI <pretmp.137_91(9), pretmp.137_92(13), T.104_19(16)>
> >
> >But the statement it tries to take the temp from hasn't had the reload
> >yet, so it doesn't pick the name.
> >
> >
> >Now, I'm not actually sure the above is valid either.
> >If not, it's a renaming problem.
> >
> >If it is valid, i can easily fix this problem.
> I'd have to think about it for a little while, but I believe the only
> time you can have a PHI node with a matching LHS/RHS is for a loop
> invariant.
>
>
> In which case it would sound to me like the PHI insertion sites were
> goof'd up since PRE should be eliminating loop invariants.
My SSA-fu is pretty weak, but I think it's easy to get such a PHI for
non-invariants...
i = 3;
j = 0;
.L4: j++;
if (i+j < 100) goto .L4
i++;
if (i+j < 1000) goto .L4
At L4 we'd have a PHI with three incoming edges, something like:
i_1 = 3;
.L4: i_2 = PHI<i_1, i_2, i_3>
i_3 = i_2 + 1;
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer