This is the mail archive of the
mailing list for the GCC project.
Re: RFC: #pragma optimization_level
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
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.