llvm dev - Mar 2018 - how to simplify FP ops with an undef operand?

> 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>

Sure, I'll post clean-ups for LangRef as the first step.

Make sure everyone's on the same page now: the general rule will be that {
fadd, fsub, fmul, fdiv, frem } undef simplification and constant folding
will follow IEEE-754 unless stated otherwise. So for fadd:

1. fadd %x, undef --> NaN
If the variable operand %x is NaN, the result must be NaN.

2. fadd undef, undef --> undef
Anything is possible.

3. fadd C, undef --> undef (where C is not NaN or Inf)
In the general constant case, the result could be anything as long as
constant operand C is not NaN or Inf.

4. fadd NaN, undef --> NaN
Same reasoning as #1; NaN propagates.

5. fadd +/-Inf, undef --> NaN
If the constant operand is +Inf or -Inf, then the result can only be +Inf
or -Inf unless the undef is NaN or the opposite Inf. If the undef is NaN or
opposite Inf, the result is NaN, so we choose undef as NaN and propagate
NaN. (If some program or known-bits is tracking that the exponent bits are
all set, we'll preserve that...)

See IEEE-754 section 7.2 for more rules.



On Sun, Mar 4, 2018 at 9:24 AM, Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> 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>
wrote:
>
> 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> 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
>
>
> _______________________________________________
> 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/20180305/423ec64b/attachment.html>

On 05.03.2018 19:27, Sanjay Patel via llvm-dev wrote:
> 3. fadd C, undef --> undef (where C is not NaN or Inf)
> In the general constant case, the result could be anything as long as 
> constant operand C is not NaN or Inf.
If C is the largest finite positive number, then (fadd C, X) cannot be a 
finite negative number. So doesn't folding (fadd C, undef) --> undef 
break the rules?

Cheers,
Nicolai

> 
> 4. fadd NaN, undef --> NaN
> Same reasoning as #1; NaN propagates.
> 
> 5. fadd +/-Inf, undef --> NaN
> If the constant operand is +Inf or -Inf, then the result can only be 
> +Inf or -Inf unless the undef is NaN or the opposite Inf. If the undef 
> is NaN or opposite Inf, the result is NaN, so we choose undef as NaN and 
> propagate NaN. (If some program or known-bits is tracking that the 
> exponent bits are all set, we'll preserve that...)
> 
> See IEEE-754 section 7.2 for more rules.
> 
> 
> 
> On Sun, Mar 4, 2018 at 9:24 AM, Chris Lattner via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> 
> 
> 
>>     On Mar 3, 2018, at 1:55 PM, Steve (Numerics) Canon
>>     <scanon at apple.com <mailto: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
> 
> 
>     _______________________________________________
>     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
>     <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
> 

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.