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

[Chris Lattner via llvm-dev]

> On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon <scanon at apple.com> wrote:
> 
> On Mar 3, 2018, at 15:54, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
> 
>>> On Mar 2, 2018, at 8:31 AM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> 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.
>> 
>> Ah yes, I completely misunderstood that!  Thank you for clarifying.  In that case, it seems perfectly reasonable for “fadd undef, 1” to fold to undef, right?
> 
> Yes, indeed.

Great! Can someone please update LangRef so we codify this for the next time I forget? :-)

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180304/8b8fd625/attachment.html>