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