[llvm-dev] how to simplify FP ops with an undef operand?
Stephen Canon via llvm-dev
llvm-dev at lists.llvm.org
Fri Mar 2 08:34:05 PST 2018
To further clarify: IEEE 754 calls the process of signaling “raising an exception” and “exception handling", but this is not what anyone else means by “exception”. Under “default exception handling”—what the llvm instructions assume—it is just setting a sticky bit in a status register that you cannot even read under the assumptions of the llvm instructions, hence operations on sNaN are side-effect free in the LLVM instruction model, just like any other input.
> On Mar 2, 2018, at 11:31 AM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180302/46be3fd9/attachment.html>
More information about the llvm-dev
mailing list