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

[Sanjay Patel via llvm-dev]

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>