This is the mail archive of the
mailing list for the GCC project.
Re: criteria.html open issues
- To: zackw at Stanford dot EDU
- Subject: Re: criteria.html open issues
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Tue, 29 May 2001 23:23:30 -0700
- CC: gcc at gcc dot gnu dot org
- References: <20010529220544.F1488@stanford.edu>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Tue, 29 May 2001 22:05:45 -0700
> From: "Zack Weinberg" <zackw@Stanford.EDU>
> Cc: firstname.lastname@example.org
> Content-Disposition: inline
> User-Agent: Mutt/1.3.18i
> On Tue, May 29, 2001 at 01:18:20AM -0700, Geoff Keating wrote:
> > "Zack Weinberg" <email@example.com> writes:
> > >
> > > We haven't really had a sensible policy about what -O levels mean,
> > Actually, we do. They're fully documented in the Info documentation:
> > `-O'
> > `-O1'
> > Optimize. Optimizing compilation takes somewhat more time, and a
> > lot more memory for a large function.
> > Without `-O', the compiler's goal is to reduce the cost of
> > compilation and to make debugging produce the expected results.
> > ...
> > `-O2'
> > Optimize even more. GCC performs nearly all supported
> > optimizations that do not involve a space-speed tradeoff. The
> > compiler does not perform loop unrolling or function inlining when
> > you specify `-O2'. As compared to `-O', this option increases
> > both compilation time and the performance of the generated code.
> Okay, so this leads me to believe that in terms of performance of
> generated code, -O0 < -O1 < -O2 for most code. How does this fit with
> the reports that -O1 is about the same, or better than, -O2 in terms
> of generated code performance, over a broad range of sources?
This means that some of the 'optimisations' switched on by O2 are
actually deoptimisations. If you could find out which ones they are,
they could be deleted, switched off, or moved to -O3 (depending on
why they depotimise).
> > `-O3'
> > Optimize yet more. `-O3' turns on all optimizations specified by
> > `-O2' and also turns on the `inline-functions' option.
> > Actually, this is slightly out-of-date. -O3 switches on the
> > optimisations that will trade space for speed.
> -frename-registers trades space for speed? And why doesn't it turn on
> -funroll-loops or -funroll-all-loops, then?
I don't know why -frename-registers is at -O3 rather than -O2; I think
this is an inconsistency.
I suspect the loop unrolling is switched off at -O3 because it is
buggy, but that's just a guess. Loop unrolling is not switched on
at any -O level.
> Why is -O3 -finline-functions in c-torture.exp as a separate
> possibility when -O3 already turns on -finline-functions?
No idea. The sources definitely switch on inlining at O3.
> > ...
> > `-Os'
> > Optimize for size. `-Os' enables all `-O2' optimizations that do
> > not typically increase code size. It also performs further
> > optimizations designed to reduce code size.
> How does this fit with the assertion, above, that -O2 does not trade
> size for speed?
-O2 will trade some size for speed, but it's not supposed to add very
much. -O3 is for the things that can cause huge expansion.
The things that -Os switches off are quite limited.
- Geoffrey Keating <firstname.lastname@example.org>