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 greatly. 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 tree-ssa level. jeff
