[LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang

Chandler Carruth chandlerc at google.com
Mon Jan 14 14:57:41 PST 2013

On Mon, Jan 14, 2013 at 2:21 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> On 1/14/2013 3:23 PM, Chandler Carruth wrote:
>> This is a great question. My plan would be: inlining doesn't impact the
>> attributes. The inliner will be free to look at both the caller and the
>> callee's attributes to choose the best inlining decision.
> The problem is not so much with the inlining decisions, as much as it is
> with keeping the attributes in the inlined code.  If you have a function
> foo, which is to be compiled at O2, and it's called from bar, whose
> optimization level is O3, then you can take the O2 code and insert it in
> the middle of the O3 code.  The problem is that in certain cases, compiling
> at O3 is not acceptable, so we can't just "upgrade" the opt level from O2
> to O3.

OK, I hadn't realized that wasn't clear.

I absolutely think that when a function has an optimization attribute, that
applies to the code in the function and all code inlined into the function.
If foo calls bar then foo's optimization level should be valid for bar, or
bar should be marked noinline, or something else.

I'm dubious about any kind of built-in way of controlling this because
there shouldn't (in a perfect world) be any code which "isn't valid" at one
optimization level, and if this is only about intent, then *if* the inliner
made the right decision to inline, then the intent of the caller should
apply to the inlined code. If it wouldn't apply, the inliner made the wrong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/7692ff89/attachment.html>

More information about the llvm-dev mailing list