This is the mail archive of the
mailing list for the GCC project.
Re: type consistency of gimple
- From: Jeffrey Law <law at redhat dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, Daniel Berlin <dberlin at dberlin dot org>, 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 10:11:41 -0600
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.firstname.lastname@example.org> <email@example.com> <44DCEDF1.firstname.lastname@example.org> <email@example.com> <44DCF0A0.firstname.lastname@example.org> <44DF6702.email@example.com> <44E074F4.firstname.lastname@example.org> <44E08E4C.email@example.com> <44E1E12C.firstname.lastname@example.org> <44E1EF05.email@example.com>
- Reply-to: law at redhat dot com
On Tue, 2006-08-15 at 11:57 -0400, 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.
No. If you look *really* closely at the conversions, all are necessary
because of need to propagate sign bits. The type selection for the
induction variables and our demand for simple ints for array indexing
causes us to generate horrific code.
Choosing better types for the induction variables and/or having a
more relaxed set of rules for array indexing would help this code
While there may be some chance to optimize away a couple of the
conversions by improving combine's ability to combine a load with
extension, we'd be much better off fixing these issues at the