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

On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <milseman at apple.com>
wrote:
>
> This is similar to how gcc defines *-fno-signed-zeros:*
> "Allow optimizations for floating point arithmetic that ignore the
> signedness of zero. IEEE arithmetic specifies the behavior of distinct
> +0.0 and -0.0 values, which then prohibits simplification of expressions
> such as x+0.0 or 0.0*x (even with *-ffinite-math-only*). This option
> implies that the sign of a zero result isn't significant."
>
> I'll revise my description to also mention that the sign of a zero
result
> isn't significant.
>
Ok, I see what you're saying here now.

>
> Also, even when you do have the second sentence, it seems to contradict
> the first sentence.
>
>
> Why does it contradict the first sentence? I meant it as a clarification
> or reinforcement of the first, not a contradiction.
>
Suppose I'm writing a backend for a target which has an instruction that
traps on any kind of NaN. Assuming I care about NaNs, I can't use such an
instruction for regular floating-point operations. However, would it be ok
to use it when the N flag is set?

If the "optimizer" may truly ignore the possibility of NaNs under the
N
flag, this would seem to be ok. However, a trap is outside the boundaries
of "undefined result". So, which half is right?

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121101/3be3166d/attachment.html>

On 11/1/2012 5:08 PM, Dan Gohman wrote:
>
> Suppose I'm writing a backend for a target which has an instruction
that
> traps on any kind of NaN. Assuming I care about NaNs, I can't use such
> an instruction for regular floating-point operations. However, would it
> be ok to use it when the N flag is set?
I've lost track here.  What kind of instruction are you talking about?

-Krzysztof


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

On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com> wrote:
> On Tue, Oct 30, 2012 at 8:28 PM, Michael Ilseman <milseman at
apple.com> wrote:
>  
> This is similar to how gcc defines -fno-signed-zeros:
> "Allow optimizations for floating point arithmetic that ignore the
signedness of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and
-0.0 values, which then prohibits simplification of expressions such as x+0.0 or
0.0*x (even with -ffinite-math-only). This option implies that the sign of a
zero result isn't significant."
> 
> I'll revise my description to also mention that the sign of a zero
result isn't significant.
> 
> Ok, I see what you're saying here now.
>  
> 
>> Also, even when you do have the second sentence, it seems to contradict
the first sentence.
>> 
> 
> Why does it contradict the first sentence? I meant it as a clarification or
reinforcement of the first, not a contradiction.
> 
> Suppose I'm writing a backend for a target which has an instruction
that traps on any kind of NaN. Assuming I care about NaNs, I can't use such
an instruction for regular floating-point operations. However, would it be ok to
use it when the N flag is set?
> 
> If the "optimizer" may truly ignore the possibility of NaNs under
the N flag, this would seem to be ok. However, a trap is outside the boundaries
of "undefined result". So, which half is right?
> 
That makes sense, I was thinking of things only in terms of the optimizer and
not in terms of instruction selection. Which do you think is better, Undefined
Behavior or that instruction selection should disregard those bits? I'd lean
towards undefined behavior, but I don't have a good feel for LLVM's
overall design for undefined behavior, poison values, etc.
> Dan
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121101/45a2d48d/attachment.html>

On 11/1/2012 6:38 PM, Michael Ilseman wrote:
>
> On Nov 1, 2012, at 3:08 PM, Dan Gohman <dan433584 at gmail.com
> <mailto:dan433584 at gmail.com>> wrote:
>>
>> If the "optimizer" may truly ignore the possibility of NaNs
under the
>> N flag, this would seem to be ok. However, a trap is outside the
>> boundaries of "undefined result". So, which half is right?
>>
>
> That makes sense, I was thinking of things only in terms of the
> optimizer and not in terms of instruction selection. Which do you think
> is better, Undefined Behavior or that instruction selection should
> disregard those bits? I'd lean towards undefined behavior, but I
don't
> have a good feel for LLVM's overall design for undefined behavior,
> poison values, etc.
I still don't understand Dan's concerns, but a target that traps on a 
quiet NaN is not IEEE compliant.  IEEE754 requires that quiet NaNs get 
propagated through operands to the results without causing exceptions.

-Krzysztof

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