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.
