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

[Michael Ilseman]

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