Re: RFC: #pragma optimization_level

["E. Weddington" <ericw at evcohs dot com>]

Richard Guenther wrote:

> On Apr 1, 2005 11:23 PM, E. Weddington <ericw@evcohs.com> wrote:
>  
>
> > Is your objection to a grain finer than the function level? Or is it to
> > the whole concept of having pragmas change the optimization level per
> > function?
> >    
>
> It would be a general objection - I thought we're trying to minimize the
> knobs the user can turn, both for simplicity and maintainance reasons.
> And I cannot, offhand, think of an example where improving the compiler
> could not do better than allowing the user specifying optimization options
> (or parameters -- anyone for changing --param values per function?  This
> would make attribute((leafify)) unnecessary, as I could bump inlining
> limits for the to-be-leafified functions).
>
> Giving fine-grained control to the user should be done only if it is for
> correctness, not for him to feel better and maybe make one version of
> the compiler generate slightly better code for him.
>
>  

That would not be the only reason....

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.)

(As an OT aside: what about increasing the number of optimization levels 
to handle fine grain control of the -f options for turning on/off 
passes? Let me know if this has been discussed and rejected previously; 
a link would be nice.)

> 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.

This has been an oft-requested feature in the AVR community (and I would 
also add for the wider embedded community), not so much to work around 
compiler issues but to work out space/speed tradeoffs. Many times the 
embedded user wants practically all of the code to be optimized for 
space except for the few timing cricital functions that need to be 
compiled for speed to run as fast as possible. There are cases where it 
is terribly inconvenient to seperate these functions into seperate files 
(e.g. access to C static variables). The compiler cannot easily make 
this design decision. So this feature is very much desired.

As to anything more fine-grained than functions (which I agree is 
insanity), or the whole inlining mess, I'll leave that to experts.

Thanks
Eric