This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: type consistency of gimple
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, Richard Guenther <richard dot guenther at gmail dot com>, GCC <gcc at gcc dot gnu dot org>, "Hubicha, Jan" <jh at suse dot cz>, "Edelsohn, David" <dje at watson dot ibm dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Tue, 15 Aug 2006 12:20:34 -0400
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.9000306@naturalbridge.com> <84fc9c000608111344l3cc4b9f0w97f104da6ed5b7ad@mail.gmail.com> <44DCEDF1.9010902@naturalbridge.com> <84fc9c000608111356n6bd522d5gd349007fdcb0cd1b@mail.gmail.com> <44DCF0A0.1060005@naturalbridge.com> <44DF6702.4060901@codesourcery.com> <44E074F4.3050402@dberlin.org> <44E08E4C.4060902@redhat.com> <44E1E12C.9080208@redhat.com> <44E1EF05.5070908@naturalbridge.com>
Kenneth Zadeck wrote:
> Nick Clifton wrote:
>> Hi Diego,
>>
>>> Jeff's point about our optimizers is also true. Nick, remember that
>>> issue with MIPS optimizations you were discussing with Jeff a few days
>>> ago? I didn't follow most of the details, but it involved ivopts and
>>> sign issues. Could you send a summary?
>> Sure:
>>
>> I was looking at how a gcc 4.1 based compiler optimized a fast
>> fourier transform algorithm for the MIPS target. What I found was the
>> it was producing much worse code than a similarly configured gcc 3.4
>> based compiler, and the culprit was the creation of the induction
>> variables used in the inner loop.
>>
> I think that you are pointing the gun at the wrong suspect. I believe
> that the true villain is some where down stream in the backend passes
> that cannot see thru the type conversions. This is one case of us
> having "degraded" the back end because the middle end likes to break
> things up into smaller pieces and the back end has too small of a window
> to look thru to do its work.
>
> We should be looking at the back end to see where it cannot see what it
> needs to see rather than trying to stop getting the middle end code into
> a reasonable form.
Uh, well, since the backend doesn't have real type information, it would
be hard to make it see through type conversions.