This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]