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

[Philip Reames via llvm-dev]

This bit of confusion comes up regularly.  It would be really good to 
get this documented in either the langref or something linked from it.

Philip


On 03/02/2018 08:34 AM, Stephen Canon via llvm-dev wrote:
> 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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> 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/4e3c3869/attachment.html>