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

[Nick Lewycky]

Robinson, Paul wrote:
> Any further thoughts on this?  If the "screw around with PassManagers"
> idea has to be replicated in each tool (clang, opt, etc) then I think
> we are really better off with an attribute that LLVM itself understands.

Sorry, this fell off my radar. Let me reply ...

> --paulr
>
>> -----Original Message-----
>> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
>> bounces at cs.uiuc.edu] On Behalf Of Robinson, Paul
>> Sent: Friday, September 20, 2013 9:36 AM
>> To: Nick Lewycky; Bedwell, Greg
>> Cc: llvm-commits at cs.uiuc.edu
>> Subject: RE: [llvm] r189101 - Add function attribute 'optnone'.
>>
>>> -----Original Message-----
>>> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
>>> bounces at cs.uiuc.edu] On Behalf Of Nick Lewycky
>>> Sent: Thursday, September 19, 2013 11:47 PM
>>> To: Bedwell, Greg
>>> Cc: llvm-commits at cs.uiuc.edu
>>> Subject: Re: [llvm] r189101 - Add function attribute 'optnone'.
>>>
>>> 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.
>>
>> Hmm, by "we" do you actually mean "clang but not opt or any other tool"
>> here?

I was referring to clang, or to your frontend if you have one.

   Some of us were chatting about this stuff yesterday and thought
>> that while the PassManager manipulation idea would work for clang it
>> wouldn't generalize to other tools.  This suggests that optnone really
>> does need to be an IR attribute.  (I could easily be wrong, I don't
>> really understand this PassManager stuff.)

Opt offers control of the passmanager all the way out to the 
command-line. It currently doesn't offer per-function control, but you 
can do the same things with the existing command-line tools if you 
really wanted. Use llvm-extract to pull out the functions, then opt, 
then llvm-link to merge them back in.

I don't understand why you think it would need to be an IR attribute 
just because the other tools wouldn't "support" it. There are plenty 
language attributes in clang which aren't represented in the IR (and 
hence not supported there).

It's also difficult to describe what goes wrong with having an optnone 
attribute. There are some questions that are hard to answer, like "what 
about module passes?" which I claim is a symptom of this having the 
wrong design. It's very clear what happens with module passes when you 
use the API directly.

Mostly I just don't like the idea of replicating "mechanism to control 
passmanager" in the IR. We already have a mechanism to control the 
passmanager, and this new one doesn't fit. If the passmanager currently 
took the list of passes to run as a module attribute, I wouldn't be so 
bothered.

Nick

>> --paulr
>>
>>>
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>