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 [EMAIL PROTECTED] (916) 791-8304
