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

[Daniel Berlin <dberlin at dberlin dot org>]

On Sun, 2006-01-15 at 18:35 -0500, Daniel Berlin wrote:
> 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
Seems a line got lost.

"The fact that they happen to give nice dataflow information was a
side-effect, not the primary goal".

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