This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Disable old loop optimizer


Hello,

> >this patch disables old loop optimizer and enables the invariant motion
> >of the new rtl loop optimizer instead by default.  This is the first
> >step towards complete removal of the old loop optimizer, which I would
> >very much like to happen in 4.1 (since it would enable some pretty
> >significant cleanups of the compiler, like removal of loop notes,
> >removal of rtl level branch prediction pass, maybe removal of libcall
> >notes, etc.).
> 
> You did post this dangerously close to April 1st, but I think you were 
> quite serious.  I've been watching for replies.
> 
> I think that Jim Wilson recently indicated that there were ways in which 
> the old RTL loop optimizer still did useful things.
> 
> Can we expect that all of the old RTL loop optimizer will be useless? 
> Certainly, one would hope that high-level loop transformations (like 
> unrolling) would be performed at the tree level.  And, loop-invariant 
> code motion will be handled by the new RTL loop optimizer.  Is there 
> anything else of interest?

as far as I know, there are the following optimizations or optimization
enhancements that are only handled by the old loop optimizer:

1) array prefetching: We now have speculative prefetching, which
   partially replaces the functionality, but it is a bit cumbersome
   to use (needs profile feedback).  Also, there are several possible
   replacement patches:
   
   -- I have developed prefetching on tree level on lno branch, which could
      be quite easily made up-to-date.
   -- On rtl branch, there is a reimplementation of the rtl level
      prefetcher (basically just the old one made to use different iv
      analysis functions), which also would be with some amount of work
      usable.

   The later patch got forgotten when I started to work on tree-ssa loop
   optimizer.  The former patch needs some performance tuning (it
   produced slightly worse code than the old rtl level optimizer on
   some benchmarks).  However both options should be doable with just a
   few days of work.

2) loop reversal (i.e. replacing "for (i = 0; i < n; i++) a[i]=i;" with
   "for (i = n - 1; i >= 0; i--) a[i]=i;", thus causing us to compare with
   zero instead of arbitrary bound, and possibly shorten the life range
   of n).  Should be trivial within linear-transform framework, the major
   problem is to decide when it is really useful.

3) ivopts do not handle induction variables with nonconstant step,
   whereas the old loop optimizer does (PR 18316, patch
   http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00142.html needs
   updating).

> I'm not keen on the disablement.  If we're going to disable it, let's 
> just remove it.  If, on the other hand, it's still useful, then perhaps 
> we shouldn't be disabling it.

My reason for proposing disabling of the old loop optimizer is that I
would like to get some testing in this situation.  The new invariant
motion is disabled by default and probably nobody ever tested it for
real (of course, it compiles all the benchmarks I have done with it, and
bootstraps on several different architectures, so probably there are not
significant problems, but anyway), and there may be side effects of
removal of the old loop optimizer that would be only revealed after the
removal.  Thus I propose first the change that is easier to revert in
case some unexpected problems occured.

The other reason is that I still want to retain the possibility to
compare with the old loop optimizer, until the patches for the missing
pieces are merged in.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]