[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
pidgeot18 at gmail.com
Tue Oct 30 21:11:13 PDT 2012
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.
News submodule owner
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev