[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level

[Joshua Cranmer]

On 10/30/2012 10:28 PM, Michael Ilseman wrote:
>
> On Oct 30, 2012, at 4:19 PM, Dan Gohman <dan433584 at gmail.com 
> <mailto:dan433584 at gmail.com>> wrote:
>
>> On Tue, Oct 30, 2012 at 2:25 PM, Michael Ilseman <milseman at apple.com 
>> <mailto:milseman at apple.com>> wrote:
>>
>>
>>     no signed zeros (S)
>>       - The optimizer is allowed to not distinguish between -0 and +0
>>     for the
>>         purposes of optimizations.
>>
>>
>> Ok, I checked LLVM CodeGen's existing -enable-no-infs-fp-math 
>> and -enable-no-nans-fp-math flags, and GCC's -ffinite-math-only flag, 
>> and they all say they apply to results as well as arguments. Do you 
>> have a good reason for varying from existing practice here?
>>
>
> The primary example I was trying to simplify with that change was x * 
> 0 ==> 0. It can be performed if you assume NIS inputs, or NS inputs 
> and N outputs. This is because Inf * 0 is NaN. In hindsight, this is 
> all making things more confusing, so I think I'll go back to 
> "arguments and results" and allow this optimization for NS. GCC gets 
> around this by lumping Inf and NaN under the same command line option.
>
>> Phrasing these from the perspective of the optimizer is a little 
>> confusing here.
>
> I think it might be clearer to change "The optimizer is allowed to …" 
> to "Allow optimizations to …" and clean up the wording a bit.
>
>> Also, "The optimizer is allowed to [not care about X]" read literally 
>> means that the semantics for X are unconstrained, which would be 
>> Undefined Behavior. For I and N here you have a second sentence which 
>> says only the result is undefined, but for S you don't.
>
> 'S' shouldn't have any undefined behavior, it just allows 
> optimizations to not distinguish between +/-0. It's perfectly legal 
> for the operation to receive a negative zero, the operation just might 
> treat it exactly the same as a positive zero. I would rather have that 
> than undefined behavior.

I'm not an expert in writing specifications, but I think defining the S 
flag in this manner would be preferable:
no signed zeros (S) - If present, then the result of a floating point 
operation with -0.0 or +0.0 as an operand is either the result of the 
operation with the original specified values or the result of the 
operation with the +0.0 or -0.0 replaced with its opposite sign.

As a side note, it's never explicitly stated in the language reference 
how much of IEEE 754 semantics floating point operations must follow.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121030/e8b4a8b9/attachment.html>