[llvm] r189101 - Add function attribute 'optnone'.

Nick Lewycky nicholas at mxc.ca
Thu Sep 19 23:47:25 PDT 2013


Greg_Bedwell at sn.scee.net wrote:
> Hi,
>
>> I think that being able to specify the optimization level on a per
> function
>> basis, like in GCC, would be useful (I think several people are
> interested in
>> this, so it may actually happen).  One of my gripes with optnone is that
> it is
>> heading in this direction but isn't solving the general problem.  I
> would be
>> much happier with a more general approach than optnone that made it
>> possible to
>> say "optimize this function at -O0" but that also allowed you to
> say"optimize
>> it at -O1" (or whatever).  Then you could optimize most of the program
> with
>> -O2/-O3 and the problematic functions with -O1 (or -O0).  So from
>> this point of
>> view I don't think optnone goes far enough.  [Having the optimization
> level on
>> the function also means that per-function passes could look up
>> whether they are
>> supposed to be doing -Og optimization and turn problematic transforms
> off].
>>
>
> This sounds good to me.  Our original proposal was for this very feature:
> http://llvm.1065342.n5.nabble.com/PROPOSAL-per-function-optimization-level-control-td57094.html
>
>
> Unfortunately, it didn't seem to register any particular interest at time,
> so we were advised to scale-back our ambitions and go for something less
> ambitious/controversial, hence 'optnone' which would still fulfil our
> primary use-case and possibly be a stepping stone to more fully blown
> per-function optimization later on.  Maybe now that there is firm talk of
> a new pass manager the proposal can be revisited w.r.t making sure the new
> implementation could support this type of feature as part of its design?

So I second Duncan's idea that we should have control over optimization 
level. Here's the thing: we already have detailed control over the 
IR-level optimizations. We can run PassManagers over particular 
functions, choose the particular pipeline, etc. I think that should be 
enough, or should be extended. The existing API for this doesn't use 
function attributes, and I think the natural extension wouldn't either.

The backend however, doesn't offer this sort of control, nor could it 
with its current design. Its pass list is fixed, each pass has semantic 
requirements that other passes ran before it. Hence, having function 
attributes for "make the backend codegen this at -O0" (there's an enum 
in codegen with four settings in it) would be fantastic.

Nick

>
> Thanks for bearing with us whilst we stumble around trying to integrate
> into the community properly!
>
> Greg Bedwell
> SN Systems - Sony Computer Entertainment Group
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify postmaster at scee.net
> This footnote also confirms that this email message has been checked for
> all known viruses.
> Sony Computer Entertainment Europe Limited
> Registered Office: 10 Great Marlborough Street, London W1F 7LP, United
> Kingdom
> Registered in England: 3277793
> **********************************************************************
>
> P Please consider the environment before printing this e-mail
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>




More information about the llvm-commits mailing list