This is the mail archive of the
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.email@example.com> <firstname.lastname@example.org> <44DCEDF1.email@example.com> <firstname.lastname@example.org> <44DCF0A0.email@example.com> <44DF6702.firstname.lastname@example.org> <44E074F4.email@example.com> <44E08E4C.firstname.lastname@example.org> <44E1E12C.email@example.com> <44E1EF05.firstname.lastname@example.org>
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?
>> 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.