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

Sean Silva silvas at purdue.edu
Fri Sep 27 12:15:13 PDT 2013


On Fri, Sep 27, 2013 at 3:03 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
>
>
>   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 think a derivative of this idea may be sufficient for the use case at
hand. Clang could effectively extract all functions marked as "optnone" (or
in the scope of #pragma optimize, or whatever) into a separate module and
link them in only after the rest of the module has been optimized (or maybe
even later, such as at link time). That seems completely generic.

-- Sean Silva


>
> 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<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<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<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<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130927/04d20b7a/attachment.html>


More information about the llvm-commits mailing list