[LLVMdev] Presenting Unsafe Math Flag to Optimizer

[Nick Lewycky]

Bill Wendling wrote:
> On Jan 13, 2010, at 4:50 PM, Devang Patel wrote:
>
>> On Wed, Jan 13, 2010 at 4:20 PM, Bill Wendling<wendling at apple.com>  wrote:
>>> Hi all,
>>>
>>> A quick question:
>>>
>>> The current implementation of the "allow unsafe math" option is to specify it via the TargetOptions object. However, this prevents the target-independent optimizer from using it. Are there any opinions (ha!) on how this could be achieved in a nice clean manner which doesn't require using the TargetOptions object in the optimizer?
>>>
>>
>> function attribute.
>
> Not a bad idea. However, how should it behave during inlining for LTO? (I really don't know the answer to this.)

A bit on the instruction, not unlike nsw/nuw/exact/inbounds. We could 
mark whether the fadd is reassociable or not:

   http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt

This handles inlining properly.

Nick

> There are three options, that you mentioned off-line:
>
> A) Caller wins
>     This could result in something the programmer didn't expect, possibly resulting in an incorrect answer.
>
> B) Don't inline
>     We potentially miss important optimizations.
>
> C) Safety first
>     The programmer could get code they didn't expect, but at least it won't result in an "incorrect" answer. I.e., it will be correct modulo LLVM bugs, but lacking any unsafe transforms they were expecting.
>
> -bw
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>