This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa vs lno] who is right?
- From: law at redhat dot com
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Dale Johannesen <dalej at apple dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Fri, 26 Mar 2004 09:06:01 -0700
- Subject: Re: [tree-ssa vs lno] who is right?
- Reply-to: law at redhat dot com
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