[PATCH] D143056: [RFC][IR] llvm.minimum/maximum NaN propagation.

[Sam Parker via Phabricator via llvm-commits]

samparker created this revision.
samparker added reviewers: spatel, nlopes, lebedev.ri, efriedma, jcranmer, arsenm, sunfish, aheejin.
Herald added subscribers: ctetreau, StephenFan, jdoerfert, kristof.beyls, dschuff.
Herald added a project: All.
samparker requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

Further align the semantics of minimum and maximum with IEEE-754-2019.

      

>From Section 6.2.3,

>   An operation that propagates a NaN operand to its result and has a single NaN
>   as an input should produce a NaN with the payload of the input NaN if
>   representable in the destination format.
>   
>   `If two or more inputs are NaN, then the payload of the resulting NaN should be
>   identical to the payload of one of the input NaNs if representable in the
>   destination format. This standard does not specify which of the input NaNs
>   will provide the payload.

This will enable us to, in some specific circumstances, to combine fcmp -> select into an intrinsic, just as what has been done for integer operations.

But do these semantics work for all our backends that use them?

For AArch64, I think this is okay for both scalar, NEON and SVE (although the textual SVE description looks like it has a bug in it, it shares the same pseudo code).

For WebAssembly, this aligns with propagating a canonical NaN but otherwise the return value is picked non-deterministically. Is it okay that LLVM IR is stricter in this case?

I haven't looked at other ISAs...


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143056

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -14803,10 +14803,10 @@
 
 Semantics:
 """"""""""
-If either operand is a NaN, returns NaN. Otherwise returns the lesser
-of the two arguments. -0.0 is considered to be less than +0.0 for this
-intrinsic. Note that these are the semantics specified in the draft of
-IEEE 754-2018.
+If one operand is a NaN, return that NaN. If both operands are NaNs, return
+either one of them. Otherwise returns the lesser of the two arguments.
+-0.0 is considered to be less than +0.0 for this intrinsic. Note that these
+are the semantics specified in IEEE 754-2019.
 
 '``llvm.maximum.*``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -14841,10 +14841,10 @@
 
 Semantics:
 """"""""""
-If either operand is a NaN, returns NaN. Otherwise returns the greater
-of the two arguments. -0.0 is considered to be less than +0.0 for this
-intrinsic. Note that these are the semantics specified in the draft of
-IEEE 754-2018.
+If one operand is a NaN, return that NaN. If both operands are NaNs, return
+either one of them. Otherwise returns the greater of the two arguments.
+-0.0 is considered to be less than +0.0 for this intrinsic. Note that these
+are the semantics specified in IEEE 754-2019.
 
 .. _int_copysign:
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D143056.493872.patch
Type: text/x-patch
Size: 1352 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230201/f68cf863/attachment.bin>