Re: criteria.html open issues

["Zack Weinberg" <zackw at stanford dot edu>]

On Sun, May 27, 2001 at 11:46:51PM -0400, dewar@gnat.com wrote:
> I do not understand the philosophy behind only enabling strict aliasing
> at -O3. Generally we often find -O3 to be a disadvantage because of the
> excessive inlining which can cause icache penalties. But strict aliasing
> seems like something that should come along with -O2.

Reality injection: -fstrict-aliasing is enabled at -O2 in all
snapshots since 2.96, and will be in 3.0.  It was turned off on the
2.95 branch to give people more time to fix their code.  It is our
understanding that most free software projects have either fixed their
code or wired in a -fno-strict-aliasing where appropriate.

-O3 turns on inlining of all functions and register renaming.  I
believe the intent is to move -frename-registers to -O2 once it no
longer causes such severe problems with debugging (i.e. once DWARF2
with location lists is the default on most common platforms).

We haven't really had a sensible policy about what -O levels mean,
except that -O2 should be a reasonable default choice (which it isn't
always; -O or -Os have been reported to be better under a rather broad
set of conditions).  This is something I'd support addressing
comprehensively in the 3.1 time frame, it's much too late for 3.0.
We'd want to look at tradeoffs between execution speed, executable
size, compiler speed, and ease of debugging; I'd suggest abandoning
the idea of 'levels of optimization' and instead tell the compiler
what you want to optimize for.

-- 
zw A man who has never gone to school may steal from a freight car, but if he
   has a university education, he may steal the whole railroad.
   	-- Theodore Roosevelt