This is the mail archive of the
mailing list for the GCC project.
Re: RFC: #pragma optimization_level
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
People are generally persuaded more easily to change optimization
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
requests for pragma-level control of optimization.
As the average life of a piece of source code is far longer than the
of a specific GCC release, users expect to compile unchanged source
many different compilers. For this reason, I think it is big mistake to
allow pragmas to turn on or off individual passes. The internal
of the compiler changes all the time, and pragmas written for one
may not make sense for another version.
The effect will be that over time, user pragmas are wrong more often
right, and the compiler will often do better when just ignoring them
(This is when people will ask for a
Pressure on GCC developers to maintain compatibility with old flags
as well. This is a recipe for disaster.
Certainly problems can arise, but I think you're seriously overstating
The C and C++ standards require that unrecognized pragmas be ignored,
and the pragmas we're talking about don't affect correctness. So the
you should see is that your code is less efficient than expected. (The
to disallow nonconforming code which go in with every release, some of
change behavior that's been stable for years, are a much bigger problem
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.