[llvm-dev] how to simplify FP ops with an undef operand?

Kaylor, Andrew via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 2 12:32:25 PST 2018


I agree with all of what Steve said (explicitly including the “Thanks for expanding, Chris” part of it).

In fact, I found myself wanting to nitpick the part about fdiv/frem trapping on divide by zero, because unless the programmer has done something to unmask that exception it will just silently set the corresponding status bit.

This is what I meant in my suggestion that we just treat sNaNs as if they were qNaNs. We can promise to provide the correct floating-point handling of operations with regard to the NaN aspect and just not make any promises regarding the correct preservation of the status bit or exception-safe scheduling of the instruction. In this regard, I don’t think an sNaN setting the INVALID flag is inherently any more dangerous that than an fptrunc instruction setting the INEXACT flag.

-Andy

From: scanon at apple.com [mailto:scanon at apple.com]
Sent: Friday, March 02, 2018 8:31 AM
To: Chris Lattner <clattner at nondot.org>
Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; llvm-dev <llvm-dev at lists.llvm.org>; John Regehr <regehr at cs.utah.edu>; Matt Arsenault <arsenm2 at gmail.com>
Subject: Re: [llvm-dev] how to simplify FP ops with an undef operand?

Thanks for expanding, Chris. Responses inline.


On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

<snip>


 - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations.  Either speculation is ok or trapping on SNaN is ok, pick one…  (and we already did :)

I see the source of confusion now.

IEEE does not define any operations as trapping on sNaN. It defines operations as raising the invalid flag on sNaN, which is *not a trap* under default exception handling. It is exactly the same as raising the underflow, overflow, inexact, or division-by-zero flag.

Any llvm instruction necessarily assumes default exception handling—otherwise, we would be using the constrained intrinsics instead. So there’s no reason for sNaN inputs to ever be undef with the llvm instructions. They are just NaNs.

– Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/1f407a4e/attachment.html>


More information about the llvm-dev mailing list