Re: LNO Branch merge proposal

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> Merging LNO is an excellent idea.  However, I'm not sure what to think
> about the timing of the proposal.  I *very* *much* want LNO to be part
> of GCC.  It is clear that to compete with the likes of ICC and Open64 we
> need this technology.  That's precisely why I don't want us rushing into
> incorporating it too early.
> 
> While it would be very cool to have LNO integrated, the fact that none
> of the optimizers are triggered by default may be a bit of a problem. 
> This was the situation we had in Tree SSA more than a year ago.
> 
> Not having the optimizers trigger by default means that there are a
> significant number of bugs that we still haven't discovered.  Bugs that
> may force us to reconsider design decisions.  Bugs that we may not be
> able to fix for a long time because of our release schedule and which
> have the potential of saturating Bugzilla.

just a note on the status of the branch (more precisely, the parts that
concern me, i.e. the lower level stuff -- everything that is enabled by
--ftree-loop-optimize -floop-optimize2):

-- basically everything from the old loop optimizer is also implemented
   in the new one (except for prefetching & some minor details)
-- I do regular bootstraps & regtesting on i686
-- the last time I have checked (about 14 days ago) it also bootstrapped
   on ia64 and ppc64
-- it compiles specint, with the following results:

   164.gzip          1400   199       703    *     1400   194       720
   175.vpr           1400   391       358    *     1400   387       362
   176.gcc           1100        --          X     1100        --
   181.mcf           1800   750       240    *     1800   738       244
   186.crafty        1000   117       857    *     1000   117       856
   197.parser        1800   399       451    *     1800   402       447
   252.eon           1300        --          X     1300        --
   253.perlbmk       1800   210       859    *     1800     0.073
   254.gap           1100   179       613    *     1100   182       603
   255.vortex        1900   231       822    *     1900   247       770
   256.bzip2         1500   334       449    *     1500   341       440
   300.twolf         3000   790       380    *     3000   790       380

   The vortex regression seems to be just "bad luck" -- some instruction
   cache problem or something like that (both oprofile and gprof localize
   the regression to the function that contains no loops at all).

I am now planning to do the performance and regression testing on other
architectures than i686 (that due to lack of registers is not really a
great place where to test things like strength reduction).

I have no great preferences about the way these things will be merged,
although I would definitely like to see them in 3.5.  It would be nice
to have it enabled by default (in the same way it is done with the
unroller, i.e. leaving the old loop optimizer alive for some time until
we can guarantee that we do not lose any significant functionality by
removing it), but I understand this might be too adventurous.

Zdenek