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

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>

On 1/19/2013 1:55 AM, Chandler Carruth wrote:
>
> -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.
It's not different at all.  The user may want to compile parts of the 
program with -ffast-math, and parts without it.  Same thing applies to 
vectorization, parallelization, or any aggressive optimizations that 
could result in small imprecisions (e.g. reassociation).  When LTO is 
introduced, the inlining code will be faced with these decisions.

-Krzysztof


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

On 1/19/2013 1:55 AM, Chandler Carruth wrote:
>
> -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.
I just thought of this example: attribute "section".  It has zero 
semantic impact on the function, and yet it is not correct to change it, 
replace it, remove it, etc.

-Krzysztof


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

On Jan 19, 2013, at 9:18 AM, Krzysztof Parzyszek <kparzysz at
codeaurora.org> wrote:
> On 1/19/2013 1:55 AM, Chandler Carruth wrote:
>> 
>> -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.
> 
> It's not different at all.  The user may want to compile parts of the
program with -ffast-math, and parts without it.  Same thing applies to
vectorization, parallelization, or any aggressive optimizations that could
result in small imprecisions (e.g. reassociation).  When LTO is introduced, the
inlining code will be faced with these decisions.
> 
It's different in that optimizations here are passes to be ran, and
fast-math is a semantic specifier. Currently, clang has fast-math support via a
command-line argument (-ffast-math), which sets fath-math flags on individual
LLVM IR instructions. Those flags don't govern the running or scheduling of
passes, but provide (relaxed) semantics for the optimizations themselves to
obey.

The optimizations, inlining, etc. happen at the LLVM IR level (below clang), so
I'll talk about the IR level now. At the IR level, fast-math flags are
per-instruction semantic flags and flagged instructions can be intermixed with
non-fast-math flagged instructions. Dropping the flags is conservative, so at
the worst case they will be dropped, but they will usually be kept and will
always be optimized correctly and safely when intermixed.

Clang currently only has a global mode with -ffast-math, but there's nothing
in LLVM stopping a per-function or even per-statement/instruction setup. That
setup would affect only the generation of LLVM IR to have those flags, and the
optimizer would be free to intermix such IR and optimize in safe/correct ways.
> -Krzysztof
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev