Re: Variable Expansion Optimization

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

Hello,

> > I'd hope that soon we'd be able to get rid of the RTL-based loop
> > unroller, but I'm perfectly willing to believe that day to be a ways
> > away...
> 
> Especially if you consider that we have *2* loop unrollers (that is, the old
> one is still around and kicking). BTW, Zdenek, what is the status on this? I
> thought we could remove the old loop unroller (and/or optimizer?) after the new
> one was merged?

my opinion is this:

1) The loop unrolling as a separate optimization should be done on
   rtl level, to avoid unnecessary compile-time overheads (optimizing
   the unrolled loop bodies separately is rarely useful and usually
   just a waste of time).  For reasons mentioned by Sebastian (possible
   loss of information during unrolling, mostly), I believe the right
   place for the unrolling optimization would be after the loop-aware
   scheduling passes (SMS), and before rest of scheduling passes and
   register allocation.
   
   Note that I am not really sure this is right; in particular I do not
   know whether the cleanup passes run that late in the compilation
   process are sufficient, so that we do not miss too large amount of
   optimizations exposed by unrolling.  This will need some testing,
   yet.

   Of course other optimizations (both tree level -- vectorizer,
   prefetching, and rtl level -- scheduling) may need to unroll
   specific loops by themselves.

2) As for the fact that we have two rtl level loop unrollers,  I propose
   to remove the old one in 3.5.  With submitted patches the new loop
   unroller should not lack any significant functionality with respect
   to the old one, and in 3.4 timeframe the new loop unroller got
   sufficiently tested.

Zdenek