RFC: #pragma optimization_level

[Dale Johannesen]

On Apr 3, 2005, at 5:31 PM, Geert Bosch wrote:
> 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.

I would hope so.  But the reason I'm doing this is that we've got a lot 
of customer
requests for pragma-level control of optimization.

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

Certainly problems can arise, but I think you're seriously overstating 
them.
The C and C++ standards require that unrecognized pragmas be ignored,
and the pragmas we're talking about don't affect correctness.  So the 
worst effect
you should see is that your code is less efficient than expected.  (The 
changes
to disallow nonconforming code which go in with every release, some of 
which
change behavior that's been stable for years, are a much bigger problem 
for users.)

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

Personally I have no strong opinion about this either way.