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

[Chandler Carruth]

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>