Re: Compilation time has more than doubled on some Polyhedron tests

[Daniel Berlin <dberlin at dberlin dot org>]

On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> 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.
> 

So it's still the same problem, just a different cause.

In this case, as i told you on IRC, the SFT's were originally meant to
let pointer analysis say things point to fields.  The fact that they
You just really seem to like the idea of an SSA for fields and arrays.

If we are going to go this route (it'd be nice, but my gut feeling is
that it is too expensive), i'll suggest publicly what i said on IRC

1. build an interval tree of the address taken and directly accessed
intervals
2. build sft's for the fields represented by those intervals
3. build sft's for the rest of the structure around those
4. Only do 2 and 3 if it's not going to result in too many SFT's.

Even *this* may not work out to be fast enough.

> > 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.
> 

Then i would suggest you do the above (or revert the patch, sadly).  You
need to do the above to come up with any kind of real limiting code more
than what was there before, and still get any kind of sane results.


> Richard.