Re: criteria.html open issues

["Albert D. Cahalan" <acahalan at cs dot uml dot edu>]

Zack Weinberg writes:
> 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.

I do not believe that this is true. Most programs have code
paths that are poorly tested. Error handling is a common case.

Very few people are even aware that aliasing is dangerous.
I work in a UNIX-centric environment with experienced OS
developers, all of whom were surprised (and horrified) to
see what the new compiler would do. Even more disturbing
was that "volatile" wouldn't fix the problem.

It isn't at all nice to have a land mine like this in a
popular optimization level.

> -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).

Nobody has ever answered this: Why does -O3 turn on inlining
of all functions????? What purpose does this serve?

> 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.

This sort of adjustment isn't even a code change AFAIK.
You just tweak a spec file.

> 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.

Throw in: chance of miscompiling non-standard code.
(so -O0 might let you get away with ++ on both sides...)