On 2005-04-01, at 23:36, Mark Mitchell wrote:
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.)
I think the point here is not quite the number of options but the character they currently
frequently have. Currently you tell the means about what the compiler should do:
-fdo-this-and-that-obscure-optimization.
I think that most people would prefer to state goals:
-ftry-to-achive-small-code-size (like -Os)
-fplese-try-to-be-nice-to-foo
-fplease-dont-care-about-aliasing.
-fgive-me-well-debuggable-code-I-dont-care-now-for-execution-speed
-fdo-as-much-as-you-think-is-good-for-execution-speed (Ok that one exists: -O9)
Thus the -Ox family is what people like. More of it would be good and the -f family
indeed degraded to compiler development help.
