This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa vs lno] who is right?


In message <1080315577.12834.102.camel@p4>, Andrew MacLeod writes:
 >On Fri, 2004-03-26 at 10:30, law@redhat.com wrote:
 >> In message <1080308082.12528.27.camel@p4>, Andrew MacLeod writes:
 >>  >I have some minor changes to copyrename in the queue, but I doubt it
 >>  >will affect this. Since there is a constant in the arguments of the PHI,
 >>  >it must have been renamed due to a copy between a temp and maxmin_Result
 >>  >elsewhere in the program. The hope was that we'd be able to get rid of
 >>  >the copy.  Looks like not, unless one or more of the PHIs can be
 >>  >optimized away. :-)
 >> I'd expect DOM to propagate the constants so that there were no uses
 >> of maxmin_Result_140, maxmin_Result_142, then I'd expect DCE to zap the
 >> useless PHIs.
 >> 
 >> Alternatively Zdenek's block trivial PHI removal code may zap them.
 >> 
 >> But again, I think step #1 is to figure out how we got them in the first
 >> place.
 >> jeff
 >> 
 >
 >It would be pretty easy, something like:
 >
 >maxmin_Result_140 = PHI <1(10)>;
 >T.55_142 = PHI <2(10)>;
 ><...>
 >maxmin_Result_133 = T.55_142
 >
 >could result in the 2 PHI nodes since we'd rename T.55_142 to
 >maxmin_Result_133 in hopes of getting rid of the copy.
 >
 >It could also happen if T.55_142 is later used as a PHI argument to a
 >maxmin_Result PHI result.
Ah yes.  Seems quite reasonable.  






jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]