RFC: #pragma optimization_level

[Geert Bosch]

On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
> In fact, I've long said that GCC had too many knobs.
>
> (For example, I just had a discussion with a customer where I 
> explained that the various optimization passes, while theoretically 
> orthogonal, are not entirely orthogonal in practice, and that truning 
> on another pass (GCSE, in this caes) avoided other bugs.  For that 
> reason, I'm not actually convinced that all the -f options for turning 
> on and off passes are useful for end-users, although they are clearly 
> useful for debugging the compiler itself.  I think we might have more 
> satisfied users if we simply had -Os, -O0, ..., -O3.  However, many 
> people in the GCC community itself, and in certain other vocal areas 
> of the user base, do not agree.)

Pragmas have even more potential for causing problems than command-line 
options.
People are generally persuaded more easily to change optimization 
options, than
to go through hundreds of source files fixing pragmas.

As the average life of a piece of source code is far longer than the 
life-span
of a specific GCC release, users expect to compile unchanged source 
code with
many different compilers. For this reason, I think it is big mistake to
allow pragmas to turn on or off individual passes. The internal 
structure
of the compiler changes all the time, and pragmas written for one 
version
may not make sense for another version.

The effect will be that over time, user pragmas are wrong more often 
than
right, and the compiler will often do better when just ignoring them 
all together.
(This is when people will ask for a 
-fignore-source-optimization-pragmas flag.)
Pressure on GCC developers to maintain compatibility with old flags 
will increase
as well. This is a recipe for disaster.

I think arguments for optimization level should have the following 
properties:
   - Obvious meaning, independent of compiler "brand" and version
   - Similar or identical to widely used pragmas in other compilers
   - Only broad definitions, to prevent over specification
   - Pragmas are only hints: the compiler may decide to honor them or not

Most cases where pragmas would be used profitably are caused by
deficiencies in the compiler. Future improvements will make the hints
gradually obsolete. Broad classifications such as "optimize size" or
"don't optimize" will stay useful longest. Very specific options
such as "optimize using the first scheduler pass" will be obsolete
very fast and are not meaningful across a range of compilers.

> optimization control seems to be something lots of people really want, 
> and other compilers do offer it.  I think it can be particularly 
> useful to people who want to work around compiler bugs in a particular 
> routine, without refactoring their code, or losing all optimization 
> for a translation unit.

There really are two parts to this:
   1. Infra-structure in the compiler to allow for varying optimization 
levels,
      such as function attributes, or even finer granularity

   2. Syntax for specifying the options in source code

The first is even useful without the last. For example, it would be 
useful
for the compiler to automatically optimize for size, if it is known at 
compile
time that a specific function will only be executed once. As the 
compilers
estimates for execution frequency improve, most people would want the 
compiler
to use balanced optimization where "hot" functions are optimized for 
speed
and cold functions are optimized for size. Here, it would even be useful
to have granularity per basic block rather than per function, so that
different optimization is in effect for cold and hot sections.

The syntax part is similar to the "register" keyword in C, which might 
have
been useful at one point, but now is mostly ignored and only retained 
for
compatibility. But doing anything much more elaborate than optimization
(off, size, some, all, inlining) corresponding to (-O0, Os, O1, O2, O3)
on a per-function basis seems a bad idea.

   -Geert