On Sun, 15 Jan 2006, Daniel Berlin wrote: > On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote: > > Richard Guenther wrote: > > > I guess the fix for PR tree-optimization/22555 could make some difference > > > if fortran uses a lot of structures with embedded arrays. Basically this > > > enables decomposing these structures for aliasing purposes and should > > > generate better code. > > > > It is perhaps noteworthy that the build times for the base run of Diego's > > SPECFP tester have increased by approx. twenty percent, with no visible gain > > in execution speed, between Jan 5th and Jan 6th, see > > <http://people.redhat.com/dnovillo/spec2000.i686/gcc/global-build-secs_elapsed.html> > > and > > <http://people.redhat.com/dnovillo/spec2000.i686/gcc/global-run-secs_elapsed.html> > > > > Again, this is why i was not convinced that array aliasing by > decomposing array's into SFT's like Richard has implemented is valuable > enough that it's worth the cost.
You are confusing the patches. The patch that caused this regression does _not_ decompose arrays into SFTs. Instead it just creates one SFT per array in a structure (and one for each other used element), like it was done before for structures that didn't contain an array. I.e. it fixed PR22555. > Right now, it's certainly going to decompose arrays in most cases for no > real benefit. The other patch, that went in on Jan 14 will decompose arrays up to 4 elements (--param salias-max-array-elements). > The code should determine whether there is even a possibility of > optimization using the SFT information before doing it (that's really > what the used part stuff is. Well, I can see if I can improve the array decomposing - but it looks like the general structure decomposing needs more attention right now, given the compile-time regressions on fortran code. Richard.
