This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Disable old loop optimizer
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 Apr 2005 10:57:33 +0200
- Subject: Re: [patch] Disable old loop optimizer
- References: <20050331212322.GA17354@atrey.karlin.mff.cuni.cz> <425C8868.6070403@codesourcery.com>
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