llvm dev - Mar 2018 - 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> 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/5483a381/attachment.html>

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>

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>

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>

> On Mar 2, 2018, at 8:31 AM, Stephen Canon <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?

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180303/1bfc1467/attachment.html>