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

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

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

On 1/14/2013 4:57 PM, Chandler Carruth wrote:
>
> 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.
That's going way too far.

For example, if a function foo, which can be compiled with -ffast-math 
calls bar, which contains code that would be "over optimized" with 
-ffast-math, then you cannot inline bar into foo, but you can inline it 
in any other function that does is compiled with the same options as bar.

> 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,
Should we wait until you see such situations then?  ;)

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

Sorry, I realized I hadn't replied to this.

On Mon, Jan 14, 2013 at 3:22 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:
> On 1/14/2013 4:57 PM, Chandler Carruth wrote:
>
>>
>> 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.
>>
>
> That's going way too far.
>
> For example, if a function foo, which can be compiled with -ffast-math
> calls bar, which contains code that would be "over optimized"
with
> -ffast-math, then you cannot inline bar into foo, but you can inline it in
> any other function that does is compiled with the same options as bar.

-ffast-math is *totally* different from these attributes, and in fact
-ffast-math is specifically not modeled as a function attribute because it
changes the fundamental semantics of an operation.

These attributes have zero semantic impact on the function, and so it is
always functionally correct to change them, replace them, merge them,
remove them, or inline code from one to the other. The question is only
what is *desirable* given the optimization levels indicated by the
attributes, and I think the desirable strategy is that the inlined code has
the caller's attribute used when optimizing. The idea is that if a
particular call site should be optimized according to X, then that call
site after inlining should be as well, even if the function being called
isn't (perhaps because there are many other callsites with different
levels).

>
>
>
>  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,
>>
>
> Should we wait until you see such situations then?  ;)

I think this is more of a theoretical invariant. If we discover such a
situation is is likely either invalid code or invalid optimizations, not an
invalid model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130118/16e3f860/attachment.html>