This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: More PRE problems
On Mon, 17 Nov 2003 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.
Even when it does remove a loop invariant *computation*, it still leaves a
temporary there, which might still be loop invariant.
SSAPRE does no actual deletion of statements.
--Dan