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
