Re: More PRE problems

[law at redhat dot com]

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.


Jeff