RFC: #pragma optimization_level

[Mark Mitchell]

Richard Guenther wrote:

> But the question is, do we want all this sort of #pragmas?  It would
> surely better to improve the compilers decisions on applying certain
> optimizations.  As usual, in most of the cases the compiler will be
> smarter than the user trying to override it (and hereby maybe only
> working around bugs in a particular compiler release).  All opposition
> that applied to stuff like attribute((leafify)) (hi Gaby!) applies here, too.
> So what is your opinion to all this babysitting-the-compiler?

I agree, in general.

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

However, function-level 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.

Finer-grained optimization control seems like something that should 
indeed have to pass a relatively strong utility test.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304