This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compilation time has more than doubled on some Polyhedron tests
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.