[llvm] 317d1a1 - [LangRef] Adjust reduce.fmin/reduce.fmax behavior for sNaN (#196053)

[via llvm-commits]

Author: Nikita Popov
Date: 2026-05-07T09:44:38+02:00
New Revision: 317d1a1591958bc646ab8ddf393706bf13ff1b3c

URL: https://github.com/llvm/llvm-project/commit/317d1a1591958bc646ab8ddf393706bf13ff1b3c
DIFF: https://github.com/llvm/llvm-project/commit/317d1a1591958bc646ab8ddf393706bf13ff1b3c.diff

LOG: [LangRef] Adjust reduce.fmin/reduce.fmax behavior for sNaN (#196053)

The reduce.fmin/reduce.fmax intrinsics are designed as unordered
reductions, just like all reductions that do not take a start value.
However, if one of the elements is sNaN, then the reduction order
matters.

I *tried* to account for this when implementing the sNaN changes for
minnum/maxnum in LangRef, but didn't correctly consider the
consequences: It's not sufficient to just say that if one value is sNaN,
either the result is NaN or its treated as qNaN.

For example, if we reduce over `<sNaN, 0.0, 1.1>` then (picking the IEEE
behavior for each maxnum):

 * maxnum(maxnum(sNaN, 0.0), 1.0) = maxnum(qNaN, 1.0) = 1.0
 * maxnum(maxnum(sNaN, 1.0), 0.0) = maxnum(qNaN, 0.0) = 0.0
 * maxnum(maxnum(0.0, 1.0), sNaN) = maxnum(1.0, sNaN) = qNaN

So if any value is sNaN, even if the result is not a NaN, it may not
actually be the maximum of the non-NaN values.

As such, change the spec to simply say the reduction is performed
non-deterministically in any order, and comment on the consequences of
that.

Added: 
    

Modified: 
    llvm/docs/LangRef.rst

Removed: 
    


################################################################################
diff  --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 83bd6c7e95ac5..179223c5ccdd6 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -21091,11 +21091,12 @@ matches the element-type of the vector input.
 This instruction has the same comparison and ``nsz`` semantics as the
 '``llvm.maxnum.*``' intrinsic.
 
-If any of the vector elements is a signaling NaN, the intrinsic will
-non-deterministically either:
+The reduction is performed in a non-deterministic order. This is only observable
+if one of the inputs is a signaling NaN.
 
- * Return a :ref:`NaN <floatnan>`.
- * Treat the signaling NaN as a quiet NaN.
+For example, if a reduction is performed over ``<sNaN, 0.0, 1.0>``, then all of
+:ref`NaN <floatnan>`, ``0.0`` and ``1.0`` are possible results, depending on
+which order is picked.
 
 Arguments:
 """"""""""
@@ -21125,11 +21126,12 @@ matches the element-type of the vector input.
 This instruction has the same comparison and ``nsz`` semantics as the
 '``llvm.minnum.*``' intrinsic.
 
-If any of the vector elements is a signaling NaN, the intrinsic will
-non-deterministically either:
+The reduction is performed in a non-deterministic order. This is only observable
+if one of the inputs is a signaling NaN.
 
- * Return a :ref:`NaN <floatnan>`.
- * Treat the signaling NaN as a quiet NaN.
+For example, if a reduction is performed over ``<sNaN, 0.0, 1.0>``, then all of
+:ref`NaN <floatnan>`, ``0.0`` and ``1.0`` are possible results, depending on
+which order is picked.
 
 Arguments:
 """"""""""