[llvm] LangRef: Clarify llvm.minnum and llvm.maxnum about sNaN and signed zero (PR #112852)
YunQiang Su via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 24 02:38:27 PST 2025
https://github.com/wzssyqa updated https://github.com/llvm/llvm-project/pull/112852
>From 60476a2bcefdfc6e9bce44fb6e1fbdf7be600060 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 18 Oct 2024 16:16:43 +0800
Subject: [PATCH 01/18] LangRef: Clarify llvm.minnum and llvm.maxnum about sNaN
The documents claims that it ignores sNaN, while in the code it may
be different.
- as the finally callback, it use libc call fmin(3)/fmax(3).
while C23 clarify that fmin(3)/fmax(3) should return NaN for sNaN vs NUM.
- on some architectures, such as aarch64, it converts to `fmaxnm`,
which returns qNaN for sNaN vs NUM.
- on RISC-V (SPEC 2019+), it converts to `fmax`, which returns NUM
for sNaN vs NUM.
Since we have introduced llvm.minimumnum and llvm.maximumnum, which
follow IEEE 754-2019's minimumNumber/maximumNumber.
So, it's time for use to clarify llvm.minnum and llvm.maxnum.
Let's define it to the libc's defination.
---
llvm/docs/LangRef.rst | 75 ++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 44 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index b922636d6c914b..46d6b3f00e5685 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,21 +16723,13 @@ type.
Semantics:
""""""""""
+Follows the IEEE754 2008 semantics for minNum, except for handling of
++0.0 vs -0.0. This matches the behavior of libm's fmin.
-Follows the IEEE-754 semantics for minNum, except for handling of
-signaling NaNs. This match's the behavior of libm's fmin.
-
-If either operand is a NaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN. If the operands compare equal,
-returns either one of the operands. For example, this means that
-fmin(+0.0, -0.0) returns either operand.
-
-Unlike the IEEE-754 2008 behavior, this does not distinguish between
-signaling and quiet NaN inputs. If a target's implementation follows
-the standard and returns a quiet NaN if either input is a signaling
-NaN, the intrinsic lowering is responsible for quieting the inputs to
-correctly return the non-NaN input (e.g. by using the equivalent of
-``llvm.canonicalize``).
+If either operand is a qNaN, returns the other non-NaN operand. Returns
+NaN only if both operands are NaN or either operand is sNaN.
+If the operands compare equal, returns either one of the operands.
+For example, this means that fmin(+0.0, -0.0) returns either operand.
.. _i_maxnum:
@@ -16774,20 +16766,13 @@ type.
Semantics:
""""""""""
-Follows the IEEE-754 semantics for maxNum except for the handling of
-signaling NaNs. This matches the behavior of libm's fmax.
+Follows the IEEE754 2008 semantics for maxNum, except for handling of
++0.0 vs -0.0. This matches the behavior of libm's fmax.
If either operand is a NaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN. If the operands compare equal,
-returns either one of the operands. For example, this means that
-fmax(+0.0, -0.0) returns either -0.0 or 0.0.
-
-Unlike the IEEE-754 2008 behavior, this does not distinguish between
-signaling and quiet NaN inputs. If a target's implementation follows
-the standard and returns a quiet NaN if either input is a signaling
-NaN, the intrinsic lowering is responsible for quieting the inputs to
-correctly return the non-NaN input (e.g. by using the equivalent of
-``llvm.canonicalize``).
+NaN only if both operands are NaN or either operand is sNaN.
+If the operands compare equal, returns either one of the operands.
+For example, this means that fmin(+0.0, -0.0) returns either operand.
.. _i_minimum:
@@ -19666,12 +19651,12 @@ The '``llvm.vector.reduce.fmax.*``' intrinsics do a floating-point
matches the element-type of the vector input.
This instruction has the same comparison semantics as the '``llvm.maxnum.*``'
-intrinsic. That is, the result will always be a number unless all elements of
-the vector are NaN. For a vector with maximum element magnitude 0.0 and
-containing both +0.0 and -0.0 elements, the sign of the result is unspecified.
+intrinsic. If the intrinsic call has the ``nnan`` fast-math flag, then the
+operation can assume that NaNs are not present in the input vector.
-If the intrinsic call has the ``nnan`` fast-math flag, then the operation can
-assume that NaNs are not present in the input vector.
+It is deprecated, since the different order of inputs may produce different
+outputs, and it is hard to optimize with Vector or SIMD extensions.
+Use '``llvm.vector.reduce.fmaximum``' or '``llvm.vector.reduce.fmaximumnum``' instead.
Arguments:
""""""""""
@@ -19699,12 +19684,12 @@ The '``llvm.vector.reduce.fmin.*``' intrinsics do a floating-point
matches the element-type of the vector input.
This instruction has the same comparison semantics as the '``llvm.minnum.*``'
-intrinsic. That is, the result will always be a number unless all elements of
-the vector are NaN. For a vector with minimum element magnitude 0.0 and
-containing both +0.0 and -0.0 elements, the sign of the result is unspecified.
+intrinsic. If the intrinsic call has the ``nnan`` fast-math flag, then the
+operation can assume that NaNs are not present in the input vector.
-If the intrinsic call has the ``nnan`` fast-math flag, then the operation can
-assume that NaNs are not present in the input vector.
+It is deprecated, since the different order of inputs may produce different
+outputs, and it is hard to optimize with Vector or SIMD extensions.
+Use '``llvm.vector.reduce.fminimum``' or '``llvm.vector.reduce.fminimumnum``' instead.
Arguments:
""""""""""
@@ -23318,13 +23303,14 @@ result type. If only ``nnan`` is set then the neutral value is ``-Infinity``.
This instruction has the same comparison semantics as the
:ref:`llvm.vector.reduce.fmax <int_vector_reduce_fmax>` intrinsic (and thus the
-'``llvm.maxnum.*``' intrinsic). That is, the result will always be a number
-unless all elements of the vector and the starting value are ``NaN``. For a
-vector with maximum element magnitude ``0.0`` and containing both ``+0.0`` and
-``-0.0`` elements, the sign of the result is unspecified.
+'``llvm.maxnum.*``' intrinsic).
To ignore the start value, the neutral value can be used.
+It is deprecated, since the different order of inputs may produce different
+outputs, and it is hard to optimize with Vector or SIMD extensions.
+Use '``llvm.vp.vector.reduce.fmaximum``' or '``llvm.vp.vector.reduce.fmaximumnum``' instead.
+
Examples:
"""""""""
@@ -23388,13 +23374,14 @@ result type. If only ``nnan`` is set then the neutral value is ``+Infinity``.
This instruction has the same comparison semantics as the
:ref:`llvm.vector.reduce.fmin <int_vector_reduce_fmin>` intrinsic (and thus the
-'``llvm.minnum.*``' intrinsic). That is, the result will always be a number
-unless all elements of the vector and the starting value are ``NaN``. For a
-vector with maximum element magnitude ``0.0`` and containing both ``+0.0`` and
-``-0.0`` elements, the sign of the result is unspecified.
+'``llvm.minnum.*``' intrinsic).
To ignore the start value, the neutral value can be used.
+It is deprecated, since the different order of inputs may produce different
+outputs, and it is hard to optimize with Vector or SIMD extensions.
+Use '``llvm.vp.vector.reduce.fminimum``' or '``llvm.vp.vector.reduce.fminimumnum``' instead.
+
Examples:
"""""""""
>From 6af6fdb5fb0b87cf97034b6d8dee2159e622cdb9 Mon Sep 17 00:00:00 2001
From: YunQiang Su <wzssyqa at gmail.com>
Date: Sat, 19 Oct 2024 01:33:13 +0800
Subject: [PATCH 02/18] minNum doesn't care about +0 vs -0
---
llvm/docs/LangRef.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 46d6b3f00e5685..8d51c0b9e9f95d 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,8 +16723,8 @@ type.
Semantics:
""""""""""
-Follows the IEEE754 2008 semantics for minNum, except for handling of
-+0.0 vs -0.0. This matches the behavior of libm's fmin.
+Follows the IEEE754 2008 semantics for minNum.
+This also matches the behavior of libm's fmin.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
@@ -16766,8 +16766,8 @@ type.
Semantics:
""""""""""
-Follows the IEEE754 2008 semantics for maxNum, except for handling of
-+0.0 vs -0.0. This matches the behavior of libm's fmax.
+Follows the IEEE754 2008 semantics for maxNum.
+This also matches the behavior of libm's fmax.
If either operand is a NaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
>From 28352d381e690ab0f36d64c3dd8ff6275a2898bc Mon Sep 17 00:00:00 2001
From: YunQiang Su <syq at debian.org>
Date: Sun, 20 Oct 2024 12:13:21 +0800
Subject: [PATCH 03/18] add history about libm
---
llvm/docs/LangRef.rst | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 8d51c0b9e9f95d..050362eb49c074 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16724,7 +16724,11 @@ type.
Semantics:
""""""""""
Follows the IEEE754 2008 semantics for minNum.
-This also matches the behavior of libm's fmin.
+This also matches the current (C23) behavior of libm's fmin.
+
+Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
+sNaN for qNaN vs sNaN. Withe recent libc versions, libc follows IEEE754-2008:
+NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
@@ -16767,7 +16771,11 @@ type.
Semantics:
""""""""""
Follows the IEEE754 2008 semantics for maxNum.
-This also matches the behavior of libm's fmax.
+This also matches the current (C23) behavior of libm's fmax.
+
+Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
+sNaN for qNaN vs sNaN. Withe recent libc versions, libc follows IEEE754-2008:
+NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
If either operand is a NaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
>From 6889356d5d7a55c592135f3fe4be42864772b87d Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Mon, 21 Oct 2024 08:56:22 +0800
Subject: [PATCH 04/18] fmin requires +0>-0
---
llvm/docs/LangRef.rst | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 050362eb49c074..3d9f92a5a1503d 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16679,7 +16679,7 @@ versions of the intrinsics respect the exception behavior.
- qNaN, invalid exception
* - ``+0.0 vs -0.0``
- - either one
+ - +0.0(max)/-0.0(min)
- +0.0(max)/-0.0(min)
- +0.0(max)/-0.0(min)
@@ -16723,8 +16723,14 @@ type.
Semantics:
""""""""""
-Follows the IEEE754 2008 semantics for minNum.
-This also matches the current (C23) behavior of libm's fmin.
+Follows the IEEE754 2008 semantics for minNum with +0.0>-0.0.
+This is more strict than current (C23) behavior of libm's fmin.
+Some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
+to archive the same behaivor of libm's fmin.
+
+For some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, they have the
+strict same instructions; thus it is quite simple for these architectures.
+For other architectures, the custom or expand methods may provide '``nsz``' flavor.
Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
sNaN for qNaN vs sNaN. Withe recent libc versions, libc follows IEEE754-2008:
@@ -16770,12 +16776,14 @@ type.
Semantics:
""""""""""
-Follows the IEEE754 2008 semantics for maxNum.
-This also matches the current (C23) behavior of libm's fmax.
+Follows the IEEE754 2008 semantics for maxNum with +0.0>-0.0.
+This is more strict than current (C23) behavior of libm's fmax.
+Some applications like Clang, can call '``llvm.maxnum.*``' with '``nsz``' attribute
+to archive the same behaivor of libm's fmax.
-Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
-sNaN for qNaN vs sNaN. Withe recent libc versions, libc follows IEEE754-2008:
-NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
+For some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, they have the
+strict same instructions; thus it is quite simple for these architectures.
+For other architectures, the custom or expand methods may provide '``nsz``' flavor.
If either operand is a NaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
>From e6830c49108af2424d8baf9fe3277efca4c36727 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Mon, 21 Oct 2024 09:11:35 +0800
Subject: [PATCH 05/18] some fix
---
llvm/docs/LangRef.rst | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 3d9f92a5a1503d..50206187df5a1e 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16729,17 +16729,16 @@ Some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attrib
to archive the same behaivor of libm's fmin.
For some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, they have the
-strict same instructions; thus it is quite simple for these architectures.
+strictly same instructions; thus it is quite simple for these architectures.
For other architectures, the custom or expand methods may provide '``nsz``' flavor.
Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
-sNaN for qNaN vs sNaN. Withe recent libc versions, libc follows IEEE754-2008:
+sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
If the operands compare equal, returns either one of the operands.
-For example, this means that fmin(+0.0, -0.0) returns either operand.
.. _i_maxnum:
@@ -16782,13 +16781,16 @@ Some applications like Clang, can call '``llvm.maxnum.*``' with '``nsz``' attrib
to archive the same behaivor of libm's fmax.
For some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, they have the
-strict same instructions; thus it is quite simple for these architectures.
+strictly same instructions; thus it is quite simple for these architectures.
For other architectures, the custom or expand methods may provide '``nsz``' flavor.
+Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
+sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
+NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
+
If either operand is a NaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
If the operands compare equal, returns either one of the operands.
-For example, this means that fmin(+0.0, -0.0) returns either operand.
.. _i_minimum:
>From e528886de9b251248c302fc659ca1e7c025dd57a Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Wed, 23 Oct 2024 09:25:07 +0800
Subject: [PATCH 06/18] add inconsistent note
---
llvm/docs/LangRef.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 50206187df5a1e..1954dfdc0909de 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16736,6 +16736,11 @@ Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
+Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
+so arithmetic feeding into a minnum can produce inconsistent results.
+Such as `fmin(sNaN+0.0, 1.0)` can produce qNaN or 1.0 depending on whether `+0.0`
+is optimized out.
+
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
If the operands compare equal, returns either one of the operands.
@@ -16788,6 +16793,11 @@ Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
+Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
+so arithmetic feeding into a maxnum can produce inconsistent results.
+Such as `fmax(sNaN+0.0, 1.0)` can produce qNaN or 1.0 depending on whether `+0.0`
+is optimized out.
+
If either operand is a NaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
If the operands compare equal, returns either one of the operands.
>From 1f5abffddc35591a4229159ceb898caf42cd1bac Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Wed, 30 Oct 2024 19:23:17 +0800
Subject: [PATCH 07/18] do more clarify
---
llvm/docs/LangRef.rst | 46 ++++++++++++++++----------
llvm/include/llvm/CodeGen/ISDOpcodes.h | 17 +++++++---
2 files changed, 40 insertions(+), 23 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 1954dfdc0909de..71a3730596f17b 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,12 +16723,21 @@ type.
Semantics:
""""""""""
-Follows the IEEE754 2008 semantics for minNum with +0.0>-0.0.
-This is more strict than current (C23) behavior of libm's fmin.
-Some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
-to archive the same behaivor of libm's fmin.
+Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
+is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
+function fmin, although not all implementations have implemented these recommended behaviors.
-For some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, they have the
+If either operand is a qNaN, returns the other non-NaN operand. Returns
+NaN only if both operands are NaN or either operand is sNaN.
+
+If the operands compare equal, returns either one of the operands.
+
+Returns -0.0 for +0.0 vs -0.0. libm doesn't require it, so that
+some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
+to archive the required behaivors of libm's fmin.
+
+Some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have the
strictly same instructions; thus it is quite simple for these architectures.
For other architectures, the custom or expand methods may provide '``nsz``' flavor.
@@ -16741,10 +16750,6 @@ so arithmetic feeding into a minnum can produce inconsistent results.
Such as `fmin(sNaN+0.0, 1.0)` can produce qNaN or 1.0 depending on whether `+0.0`
is optimized out.
-If either operand is a qNaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN or either operand is sNaN.
-If the operands compare equal, returns either one of the operands.
-
.. _i_maxnum:
'``llvm.maxnum.*``' Intrinsic
@@ -16780,12 +16785,21 @@ type.
Semantics:
""""""""""
-Follows the IEEE754 2008 semantics for maxNum with +0.0>-0.0.
-This is more strict than current (C23) behavior of libm's fmax.
-Some applications like Clang, can call '``llvm.maxnum.*``' with '``nsz``' attribute
-to archive the same behaivor of libm's fmax.
+Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
+is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
+function fmin, although not all implementations have implemented these recommended behaviors.
-For some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, they have the
+If either operand is a qNaN, returns the other non-NaN operand. Returns
+NaN only if both operands are NaN or either operand is sNaN.
+
+If the operands compare equal, returns either one of the operands.
+
+Returns -0.0 for +0.0 vs -0.0. libm doesn't require it, so that
+some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
+to archive the required behaivors of libm's fmin.
+
+Some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have the
strictly same instructions; thus it is quite simple for these architectures.
For other architectures, the custom or expand methods may provide '``nsz``' flavor.
@@ -16798,10 +16812,6 @@ so arithmetic feeding into a maxnum can produce inconsistent results.
Such as `fmax(sNaN+0.0, 1.0)` can produce qNaN or 1.0 depending on whether `+0.0`
is optimized out.
-If either operand is a NaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN or either operand is sNaN.
-If the operands compare equal, returns either one of the operands.
-
.. _i_minimum:
'``llvm.minimum.*``' Intrinsic
diff --git a/llvm/include/llvm/CodeGen/ISDOpcodes.h b/llvm/include/llvm/CodeGen/ISDOpcodes.h
index fd8784a4c10034..21de4d28ded0ed 100644
--- a/llvm/include/llvm/CodeGen/ISDOpcodes.h
+++ b/llvm/include/llvm/CodeGen/ISDOpcodes.h
@@ -1021,13 +1021,20 @@ enum NodeType {
LRINT,
LLRINT,
- /// FMINNUM/FMAXNUM - Perform floating-point minimum or maximum on two
- /// values.
+ /// FMINNUM/FMAXNUM - Perform floating-point minimum maximum on two values,
+ /// following IEEE-754 definitions.
///
- /// In the case where a single input is a NaN (either signaling or quiet),
- /// the non-NaN input is returned.
+ /// If one input is a signaling NaN, returns a quiet NaN. This matches
+ /// IEEE-754 2008's minnum/maxnum behavior for signaling NaNs (which differs
+ /// from 2019).
+ ///
+ /// These treat -0 as ordered less than +0, matching the behavior of IEEE-754
+ /// 2019's minimumNumber/maximumNumber.
///
- /// The return value of (FMINNUM 0.0, -0.0) could be either 0.0 or -0.0.
+ /// Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
+ /// so arithmetic feeding into a minnum/maxnum can produce inconsistent
+ /// results. FMAXIMUN/FMINIMUM or FMAXIMUMNUM/FMINIMUMNUM may be better choice
+ /// for non-distinction of sNaN/qNaN handling.
FMINNUM,
FMAXNUM,
>From 91e3843d318484b9d40c471d1e5406196d87bcc0 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 1 Nov 2024 09:02:34 +0800
Subject: [PATCH 08/18] some improvement on wording
---
llvm/docs/LangRef.rst | 34 +++++++++++---------------
llvm/include/llvm/CodeGen/ISDOpcodes.h | 4 +--
2 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 71a3730596f17b..615681b129e7ec 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16731,15 +16731,12 @@ function fmin, although not all implementations have implemented these recommend
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
-If the operands compare equal, returns either one of the operands.
+This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned.
+To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use the nsz
+attribute on the intrinsic call.
-Returns -0.0 for +0.0 vs -0.0. libm doesn't require it, so that
-some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
-to archive the required behaivors of libm's fmin.
-
-Some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have the
-strictly same instructions; thus it is quite simple for these architectures.
-For other architectures, the custom or expand methods may provide '``nsz``' flavor.
+Some architectures, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have instructions that match
+these semantics exactly; thus it is quite simple for these architectures.
Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
@@ -16793,15 +16790,12 @@ function fmin, although not all implementations have implemented these recommend
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or either operand is sNaN.
-If the operands compare equal, returns either one of the operands.
-
-Returns -0.0 for +0.0 vs -0.0. libm doesn't require it, so that
-some applications like Clang, can call '``llvm.minnum.*``' with '``nsz``' attribute
-to archive the required behaivors of libm's fmin.
+This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned.
+To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use the nsz
+attribute on the intrinsic call.
-Some architecturs, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have the
-strictly same instructions; thus it is quite simple for these architectures.
-For other architectures, the custom or expand methods may provide '``nsz``' flavor.
+Some architectures, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have instructions that match
+these semantics exactly; thus it is quite simple for these architectures.
Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
@@ -19693,7 +19687,7 @@ intrinsic. If the intrinsic call has the ``nnan`` fast-math flag, then the
operation can assume that NaNs are not present in the input vector.
It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with Vector or SIMD extensions.
+outputs, and it is hard to optimize with vector or SIMD extensions.
Use '``llvm.vector.reduce.fmaximum``' or '``llvm.vector.reduce.fmaximumnum``' instead.
Arguments:
@@ -19726,7 +19720,7 @@ intrinsic. If the intrinsic call has the ``nnan`` fast-math flag, then the
operation can assume that NaNs are not present in the input vector.
It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with Vector or SIMD extensions.
+outputs, and it is hard to optimize with vector or SIMD extensions.
Use '``llvm.vector.reduce.fminimum``' or '``llvm.vector.reduce.fminimumnum``' instead.
Arguments:
@@ -23346,7 +23340,7 @@ This instruction has the same comparison semantics as the
To ignore the start value, the neutral value can be used.
It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with Vector or SIMD extensions.
+outputs, and it is hard to optimize with vector or SIMD extensions.
Use '``llvm.vp.vector.reduce.fmaximum``' or '``llvm.vp.vector.reduce.fmaximumnum``' instead.
Examples:
@@ -23417,7 +23411,7 @@ This instruction has the same comparison semantics as the
To ignore the start value, the neutral value can be used.
It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with Vector or SIMD extensions.
+outputs, and it is hard to optimize with vector or SIMD extensions.
Use '``llvm.vp.vector.reduce.fminimum``' or '``llvm.vp.vector.reduce.fminimumnum``' instead.
Examples:
diff --git a/llvm/include/llvm/CodeGen/ISDOpcodes.h b/llvm/include/llvm/CodeGen/ISDOpcodes.h
index 21de4d28ded0ed..8032e8202638af 100644
--- a/llvm/include/llvm/CodeGen/ISDOpcodes.h
+++ b/llvm/include/llvm/CodeGen/ISDOpcodes.h
@@ -1022,10 +1022,10 @@ enum NodeType {
LLRINT,
/// FMINNUM/FMAXNUM - Perform floating-point minimum maximum on two values,
- /// following IEEE-754 definitions.
+ /// following IEEE-754 definitions except for signed zero behavior.
///
/// If one input is a signaling NaN, returns a quiet NaN. This matches
- /// IEEE-754 2008's minnum/maxnum behavior for signaling NaNs (which differs
+ /// IEEE-754 2008's minNum/maxNum behavior for signaling NaNs (which differs
/// from 2019).
///
/// These treat -0 as ordered less than +0, matching the behavior of IEEE-754
>From d326d8c10f34de240c59a1b8bc32a64a55a7c408 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 1 Nov 2024 09:27:03 +0800
Subject: [PATCH 09/18] libc may be different
---
llvm/docs/LangRef.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 615681b129e7ec..a5e5ea93d81296 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16738,9 +16738,9 @@ attribute on the intrinsic call.
Some architectures, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have instructions that match
these semantics exactly; thus it is quite simple for these architectures.
-Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
-sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
-NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
+In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
+even in the same release of a single libm implemention. Such as in glibc 2.24, the Arm64 asm implemention
+has different behaviour with the generic C implemention.
Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a minnum can produce inconsistent results.
@@ -16797,9 +16797,9 @@ attribute on the intrinsic call.
Some architectures, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have instructions that match
these semantics exactly; thus it is quite simple for these architectures.
-Historically, libc returns NUM for NUM vs (sNaN or qNaN), and may return
-sNaN for qNaN vs sNaN. With the recent libc versions, libc follows IEEE754-2008:
-NUM vs sNaN -> qNaN; NUM vs qNaN -> NUM; qNaN vs sNaN -> qNaN; sNaN vs sNaN -> qNaN.
+In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
+even in the same release of a single libm implemention. Such as in glibc 2.24, the Arm64 asm implemention
+has different behaviour with the generic C implemention.
Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a maxnum can produce inconsistent results.
>From f3e68ca02219d5db66513cd053c59e460fb765bf Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Tue, 3 Dec 2024 09:34:42 +0800
Subject: [PATCH 10/18] Update
---
llvm/docs/LangRef.rst | 47 ++++++++++++++++----------
llvm/include/llvm/CodeGen/ISDOpcodes.h | 3 ++
2 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index a5e5ea93d81296..4800200e42b265 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16726,26 +16726,32 @@ Semantics:
Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
-function fmin, although not all implementations have implemented these recommended behaviors.
+function `fmin`, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN or either operand is sNaN.
+NaN only if both operands are NaN or if either operand is sNaN.
This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned.
To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use the nsz
attribute on the intrinsic call.
-Some architectures, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have instructions that match
-these semantics exactly; thus it is quite simple for these architectures.
+If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
+and IEEE 754: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
+
+Some architectures, such as ARMv8 (FMINNM), LoongArch (fmin), MIPSr6 (min.fmt), PowerPC/VSX (xsmindp),
+have instructions that match these semantics exactly; thus it is quite simple for these architectures.
+Some architectures have similiar while they are not exact equivalent. Such as x86 implements `MINPS`,
+which implements the semantics of C code `a<b?a:b`: NUM vs qNaN always return qNaN. `MINPS` can be used
+if `nsz` and `nnan` are given.
+
In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
-even in the same release of a single libm implemention. Such as in glibc 2.24, the Arm64 asm implemention
-has different behaviour with the generic C implemention.
+even in the same release of a single libm implemention.
-Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
+Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a minnum can produce inconsistent results.
-Such as `fmin(sNaN+0.0, 1.0)` can produce qNaN or 1.0 depending on whether `+0.0`
-is optimized out.
+For example, `maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd`
+is folded.
.. _i_maxnum:
@@ -16785,26 +16791,31 @@ Semantics:
Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
-function fmin, although not all implementations have implemented these recommended behaviors.
+function `fmax`, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN or either operand is sNaN.
+NaN only if both operands are NaN or if either operand is sNaN.
This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned.
To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use the nsz
attribute on the intrinsic call.
-Some architectures, such as ARMv8, LoongArch, MIPSr6, PowerPC/VSX, have instructions that match
-these semantics exactly; thus it is quite simple for these architectures.
+If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
+and IEEE 754: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
+
+Some architectures, such as ARMv8 (FMAXNM), LoongArch (fmax), MIPSr6 (max.fmt), PowerPC/VSX (xsmaxdp),
+have instructions that match these semantics exactly; thus it is quite simple for these architectures.
+Some architectures have similiar while they are not exact equivalent. Such as x86 implements `MAXPS`,
+which implements the semantics of C code `a>b?a:b`: NUM vs qNaN always return qNaN. `MAXPS` can be used
+if `nsz` and `nnan` are given.
In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
-even in the same release of a single libm implemention. Such as in glibc 2.24, the Arm64 asm implemention
-has different behaviour with the generic C implemention.
+even in the same release of a single libm implemention.
-Note that that arithmetic on an sNaN doesn't consistently produce a qNaN,
+Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a maxnum can produce inconsistent results.
-Such as `fmax(sNaN+0.0, 1.0)` can produce qNaN or 1.0 depending on whether `+0.0`
-is optimized out.
+For example, `maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd`
+is folded.
.. _i_minimum:
diff --git a/llvm/include/llvm/CodeGen/ISDOpcodes.h b/llvm/include/llvm/CodeGen/ISDOpcodes.h
index 8032e8202638af..678ed8c8a6fa3a 100644
--- a/llvm/include/llvm/CodeGen/ISDOpcodes.h
+++ b/llvm/include/llvm/CodeGen/ISDOpcodes.h
@@ -1048,6 +1048,9 @@ enum NodeType {
///
/// These treat -0 as ordered less than +0, matching the behavior of IEEE-754
/// 2019's minimumNumber/maximumNumber.
+ ///
+ /// Deprecated, and will be removed soon, as FMINNUM/FMAXNUM have the same
+ /// semantics now.
FMINNUM_IEEE,
FMAXNUM_IEEE,
>From 03c1688f2c01b0a3f43f5ae5056326055cceb501 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Wed, 4 Dec 2024 10:33:47 +0800
Subject: [PATCH 11/18] highlight IEEE-754-2008
---
llvm/docs/LangRef.rst | 32 ++++++++++++++++----------------
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 4800200e42b265..936da6fe84bc79 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,20 +16723,20 @@ type.
Semantics:
""""""""""
-Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
-of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
+Follows the semantics of minNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the minNum semantics, if either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
function `fmin`, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or if either operand is sNaN.
-This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned.
-To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use the nsz
-attribute on the intrinsic call.
+This behavior is stricter than minNum in IEEE-754-2008, where either zero may be returned.
+To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use
+the nsz attribute.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
-and IEEE 754: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
+and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
Some architectures, such as ARMv8 (FMINNM), LoongArch (fmin), MIPSr6 (min.fmt), PowerPC/VSX (xsmindp),
have instructions that match these semantics exactly; thus it is quite simple for these architectures.
@@ -16788,20 +16788,20 @@ type.
Semantics:
""""""""""
-Follows the IEEE-754 semantics for minNum, except that -0.0 < +0.0 for the purposes
-of this intrinsic. As for signaling NaNs, per the IEEE-754 semantics, if either operand
+Follows the semantics of maxNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the maxNum semantics, if either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
function `fmax`, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or if either operand is sNaN.
-This behavior is more strict than the definition in C and IEEE 754, where either zero may be returned.
-To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use the nsz
-attribute on the intrinsic call.
+This behavior is stricter than maxNum in IEEE-754-2008, where either zero may be returned.
+To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use
+the nsz attribute.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
-and IEEE 754: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
+and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
Some architectures, such as ARMv8 (FMAXNM), LoongArch (fmax), MIPSr6 (max.fmt), PowerPC/VSX (xsmaxdp),
have instructions that match these semantics exactly; thus it is quite simple for these architectures.
@@ -21998,7 +21998,7 @@ This is an overloaded intrinsic.
Overview:
"""""""""
-Predicated floating-point IEEE-754 minNum of two vectors of floating-point values.
+Predicated floating-point IEEE-754-2008 minNum of two vectors of floating-point values.
Arguments:
@@ -22047,7 +22047,7 @@ This is an overloaded intrinsic.
Overview:
"""""""""
-Predicated floating-point IEEE-754 maxNum of two vectors of floating-point values.
+Predicated floating-point IEEE-754-2008 maxNum of two vectors of floating-point values.
Arguments:
@@ -28091,7 +28091,7 @@ The third argument specifies the exception behavior as described above.
Semantics:
""""""""""
-This function follows the IEEE-754 semantics for maxNum.
+This function follows the IEEE-754-2008 semantics for maxNum.
'``llvm.experimental.constrained.minnum``' Intrinsic
@@ -28123,7 +28123,7 @@ The third argument specifies the exception behavior as described above.
Semantics:
""""""""""
-This function follows the IEEE-754 semantics for minNum.
+This function follows the IEEE-754-2008 semantics for minNum.
'``llvm.experimental.constrained.maximum``' Intrinsic
>From 460b489e5d0d7d11e42a5d0b67f47430c86b82c2 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Thu, 5 Dec 2024 09:52:02 +0800
Subject: [PATCH 12/18] define with 2019; remove deprecated about vector*
---
llvm/docs/LangRef.rst | 40 +++++++++++-----------------------------
1 file changed, 11 insertions(+), 29 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 936da6fe84bc79..508a8b1e4957a3 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,24 +16723,23 @@ type.
Semantics:
""""""""""
-Follows the semantics of minNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
-of this intrinsic. As for signaling NaNs, per the minNum semantics, if either operand
+Follows the semantics of mininumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
function `fmin`, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or if either operand is sNaN.
-This behavior is stricter than minNum in IEEE-754-2008, where either zero may be returned.
-To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use
-the nsz attribute.
+IEEE-754-2008 defines minNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
+stricter than minNum in IEEE-754-2008, where either zero may be returned. To achieve the same permissiveness,
+the backend may implement the nsz attribute, and one may use the nsz attribute.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
Some architectures, such as ARMv8 (FMINNM), LoongArch (fmin), MIPSr6 (min.fmt), PowerPC/VSX (xsmindp),
have instructions that match these semantics exactly; thus it is quite simple for these architectures.
-Some architectures have similiar while they are not exact equivalent. Such as x86 implements `MINPS`,
+Some architectures have similiar ones while they are not exact equivalent. Such as x86 implements `MINPS`,
which implements the semantics of C code `a<b?a:b`: NUM vs qNaN always return qNaN. `MINPS` can be used
if `nsz` and `nnan` are given.
@@ -16788,24 +16787,23 @@ type.
Semantics:
""""""""""
-Follows the semantics of maxNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
-of this intrinsic. As for signaling NaNs, per the maxNum semantics, if either operand
+Follows the semantics of maxinumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
-function `fmax`, although not all implementations have implemented these recommended behaviors.
+function `fmin`, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns
NaN only if both operands are NaN or if either operand is sNaN.
-This behavior is stricter than maxNum in IEEE-754-2008, where either zero may be returned.
-To achieve the same permissiveness, the backend may implement the nsz attribute, and one may use
-the nsz attribute.
+IEEE-754-2008 defines maxNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
+stricter than minNum in IEEE-754-2008, where either zero may be returned. To achieve the same permissiveness,
+the backend may implement the nsz attribute, and one may use the nsz attribute.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
Some architectures, such as ARMv8 (FMAXNM), LoongArch (fmax), MIPSr6 (max.fmt), PowerPC/VSX (xsmaxdp),
have instructions that match these semantics exactly; thus it is quite simple for these architectures.
-Some architectures have similiar while they are not exact equivalent. Such as x86 implements `MAXPS`,
+Some architectures have similiar ones while they are not exact equivalent. Such as x86 implements `MAXPS`,
which implements the semantics of C code `a>b?a:b`: NUM vs qNaN always return qNaN. `MAXPS` can be used
if `nsz` and `nnan` are given.
@@ -19697,10 +19695,6 @@ This instruction has the same comparison semantics as the '``llvm.maxnum.*``'
intrinsic. If the intrinsic call has the ``nnan`` fast-math flag, then the
operation can assume that NaNs are not present in the input vector.
-It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with vector or SIMD extensions.
-Use '``llvm.vector.reduce.fmaximum``' or '``llvm.vector.reduce.fmaximumnum``' instead.
-
Arguments:
""""""""""
The argument to this intrinsic must be a vector of floating-point values.
@@ -19730,10 +19724,6 @@ This instruction has the same comparison semantics as the '``llvm.minnum.*``'
intrinsic. If the intrinsic call has the ``nnan`` fast-math flag, then the
operation can assume that NaNs are not present in the input vector.
-It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with vector or SIMD extensions.
-Use '``llvm.vector.reduce.fminimum``' or '``llvm.vector.reduce.fminimumnum``' instead.
-
Arguments:
""""""""""
The argument to this intrinsic must be a vector of floating-point values.
@@ -23350,10 +23340,6 @@ This instruction has the same comparison semantics as the
To ignore the start value, the neutral value can be used.
-It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with vector or SIMD extensions.
-Use '``llvm.vp.vector.reduce.fmaximum``' or '``llvm.vp.vector.reduce.fmaximumnum``' instead.
-
Examples:
"""""""""
@@ -23421,10 +23407,6 @@ This instruction has the same comparison semantics as the
To ignore the start value, the neutral value can be used.
-It is deprecated, since the different order of inputs may produce different
-outputs, and it is hard to optimize with vector or SIMD extensions.
-Use '``llvm.vp.vector.reduce.fminimum``' or '``llvm.vp.vector.reduce.fminimumnum``' instead.
-
Examples:
"""""""""
>From 47d7f0913a5c9b594aef82de0ea0d3799a7ee1cc Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Mon, 9 Dec 2024 10:05:36 +0800
Subject: [PATCH 13/18] fix typo minimum
---
llvm/docs/LangRef.rst | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 508a8b1e4957a3..6d4909918897d1 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,12 +16723,14 @@ type.
Semantics:
""""""""""
-Follows the semantics of mininumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
+Follows the semantics of minimumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
function `fmin`, although not all implementations have implemented these recommended behaviors.
-If either operand is a qNaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN or if either operand is sNaN.
+If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
+NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
+so arithmetic feeding into a minnum can produce inconsistent results. For example,
+`minnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
IEEE-754-2008 defines minNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
stricter than minNum in IEEE-754-2008, where either zero may be returned. To achieve the same permissiveness,
@@ -16743,15 +16745,9 @@ Some architectures have similiar ones while they are not exact equivalent. Such
which implements the semantics of C code `a<b?a:b`: NUM vs qNaN always return qNaN. `MINPS` can be used
if `nsz` and `nnan` are given.
-
In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
even in the same release of a single libm implemention.
-Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
-so arithmetic feeding into a minnum can produce inconsistent results.
-For example, `maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd`
-is folded.
-
.. _i_maxnum:
'``llvm.maxnum.*``' Intrinsic
@@ -16787,12 +16783,14 @@ type.
Semantics:
""""""""""
-Follows the semantics of maxinumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
+Follows the semantics of maximumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
function `fmin`, although not all implementations have implemented these recommended behaviors.
-If either operand is a qNaN, returns the other non-NaN operand. Returns
-NaN only if both operands are NaN or if either operand is sNaN.
+If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
+NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
+so arithmetic feeding into a maxnum can produce inconsistent results. For example,
+`maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
IEEE-754-2008 defines maxNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
stricter than minNum in IEEE-754-2008, where either zero may be returned. To achieve the same permissiveness,
@@ -16810,11 +16808,6 @@ if `nsz` and `nnan` are given.
In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
even in the same release of a single libm implemention.
-Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
-so arithmetic feeding into a maxnum can produce inconsistent results.
-For example, `maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd`
-is folded.
-
.. _i_minimum:
'``llvm.minimum.*``' Intrinsic
>From 57d958bbea2f8eb414f57a60ddb4aca13df26e48 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Wed, 22 Jan 2025 09:46:28 +0800
Subject: [PATCH 14/18] some fix
---
llvm/docs/LangRef.rst | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 6d4909918897d1..43429534402733 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16725,7 +16725,7 @@ Semantics:
""""""""""
Follows the semantics of minimumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
-function `fmin`, although not all implementations have implemented these recommended behaviors.
+function ``fmin``, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
@@ -16733,8 +16733,7 @@ so arithmetic feeding into a minnum can produce inconsistent results. For exampl
`minnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
IEEE-754-2008 defines minNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
-stricter than minNum in IEEE-754-2008, where either zero may be returned. To achieve the same permissiveness,
-the backend may implement the nsz attribute, and one may use the nsz attribute.
+stricter than minNum in IEEE-754-2008, where either zero may be returned.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
@@ -16785,7 +16784,7 @@ Semantics:
""""""""""
Follows the semantics of maximumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
-function `fmin`, although not all implementations have implemented these recommended behaviors.
+function ``fmax``, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
@@ -16793,8 +16792,7 @@ so arithmetic feeding into a maxnum can produce inconsistent results. For exampl
`maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
IEEE-754-2008 defines maxNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
-stricter than minNum in IEEE-754-2008, where either zero may be returned. To achieve the same permissiveness,
-the backend may implement the nsz attribute, and one may use the nsz attribute.
+stricter than minNum in IEEE-754-2008, where either zero may be returned.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
>From 0b80b40e4ad81ac9bc48e742df3e2d62656c3c3c Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 24 Jan 2025 14:19:23 +0800
Subject: [PATCH 15/18] Improve some wording
---
llvm/docs/LangRef.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 43429534402733..428e842fef6f1a 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16730,9 +16730,9 @@ function ``fmin``, although not all implementations have implemented these recom
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a minnum can produce inconsistent results. For example,
-`minnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
+`minnum(fadd(sNaN, -0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
-IEEE-754-2008 defines minNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
+IEEE-754-2008 defines minNum, and it was removed in IEEE-754-2019. The behavior of this intrinsic is
stricter than minNum in IEEE-754-2008, where either zero may be returned.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
@@ -16744,7 +16744,7 @@ Some architectures have similiar ones while they are not exact equivalent. Such
which implements the semantics of C code `a<b?a:b`: NUM vs qNaN always return qNaN. `MINPS` can be used
if `nsz` and `nnan` are given.
-In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
+For existing libc implementations, the behaviors of fmin may be quite different on sNaN and signed zero behaviors,
even in the same release of a single libm implemention.
.. _i_maxnum:
@@ -16789,9 +16789,9 @@ function ``fmax``, although not all implementations have implemented these recom
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a maxnum can produce inconsistent results. For example,
-`maxnum(fadd(sNaN, 0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
+`maxnum(fadd(sNaN, -0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
-IEEE-754-2008 defines maxNum, and it is removed in IEEE-754-2019. The behavior of this intrinsic is
+IEEE-754-2008 defines maxNum, and it was removed in IEEE-754-2019. The behavior of this intrinsic is
stricter than minNum in IEEE-754-2008, where either zero may be returned.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
@@ -16803,7 +16803,7 @@ Some architectures have similiar ones while they are not exact equivalent. Such
which implements the semantics of C code `a>b?a:b`: NUM vs qNaN always return qNaN. `MAXPS` can be used
if `nsz` and `nnan` are given.
-In the real libc worlds, the bebhaviors of fmin may be quite different on sNaN and signed zero behaviors,
+For existing libc implementations, the behaviors of fmin may be quite different on sNaN and signed zero behaviors,
even in the same release of a single libm implemention.
.. _i_minimum:
>From 870ba138d782fcc83435e5706747fd5742c15417 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 24 Jan 2025 14:41:06 +0800
Subject: [PATCH 16/18] Define with 2008
---
llvm/docs/LangRef.rst | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 428e842fef6f1a..416bcc1b51c082 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16723,8 +16723,9 @@ type.
Semantics:
""""""""""
-Follows the semantics of minimumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
-is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
+Follows the semantics of minNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the minNum semantics, if either operand is sNaN,
+the result is qNaN. This matches the recommended behavior for the libm
function ``fmin``, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
@@ -16732,8 +16733,8 @@ NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consis
so arithmetic feeding into a minnum can produce inconsistent results. For example,
`minnum(fadd(sNaN, -0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
-IEEE-754-2008 defines minNum, and it was removed in IEEE-754-2019. The behavior of this intrinsic is
-stricter than minNum in IEEE-754-2008, where either zero may be returned.
+IEEE-754-2008 defines minNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
+defines :ref:`minimumNumber <llvm-minimumnum-intrinsic>`.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
@@ -16782,8 +16783,9 @@ type.
Semantics:
""""""""""
-Follows the semantics of maximumNumber in IEEE-754-2019, except for signaling NaNs. If either operand
-is an sNaN, the result is always a qNaN. This matches the recommended behavior for the libm
+Follows the semantics of maxNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes
+of this intrinsic. As for signaling NaNs, per the maxNum semantics, if either operand is sNaN,
+the result is qNaN. This matches the recommended behavior for the libm
function ``fmax``, although not all implementations have implemented these recommended behaviors.
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
@@ -16791,8 +16793,8 @@ NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consis
so arithmetic feeding into a maxnum can produce inconsistent results. For example,
`maxnum(fadd(sNaN, -0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
-IEEE-754-2008 defines maxNum, and it was removed in IEEE-754-2019. The behavior of this intrinsic is
-stricter than minNum in IEEE-754-2008, where either zero may be returned.
+IEEE-754-2008 defines maxNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
+defines :ref:`maximumNumber <llvm-maximumnum-intrinsic>`.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
>From 580966494ea4fb227c5e313c0cb26dc836981644 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 24 Jan 2025 14:51:16 +0800
Subject: [PATCH 17/18] Use double-backticks
---
llvm/docs/LangRef.rst | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 416bcc1b51c082..f4c1cd36546766 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16731,19 +16731,19 @@ function ``fmin``, although not all implementations have implemented these recom
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a minnum can produce inconsistent results. For example,
-`minnum(fadd(sNaN, -0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
+``minnum(fadd(sNaN, -0.0), 1.0)`` can produce qNaN or 1.0 depending on whether ``fadd`` is folded.
IEEE-754-2008 defines minNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
defines :ref:`minimumNumber <llvm-minimumnum-intrinsic>`.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
-and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.
+and IEEE-754-2008: the result of ``minnum(-0.0, +0.0)`` may be either -0.0 or +0.0.
Some architectures, such as ARMv8 (FMINNM), LoongArch (fmin), MIPSr6 (min.fmt), PowerPC/VSX (xsmindp),
have instructions that match these semantics exactly; thus it is quite simple for these architectures.
-Some architectures have similiar ones while they are not exact equivalent. Such as x86 implements `MINPS`,
-which implements the semantics of C code `a<b?a:b`: NUM vs qNaN always return qNaN. `MINPS` can be used
-if `nsz` and `nnan` are given.
+Some architectures have similiar ones while they are not exact equivalent. Such as x86 implements ``MINPS``,
+which implements the semantics of C code ``a<b?a:b``: NUM vs qNaN always return qNaN. ``MINPS`` can be used
+if ``nsz`` and ``nnan`` are given.
For existing libc implementations, the behaviors of fmin may be quite different on sNaN and signed zero behaviors,
even in the same release of a single libm implemention.
@@ -16791,7 +16791,7 @@ function ``fmax``, although not all implementations have implemented these recom
If either operand is a qNaN, returns the other non-NaN operand. Returns NaN only if both operands are
NaN or if either operand is sNaN. Note that arithmetic on an sNaN doesn't consistently produce a qNaN,
so arithmetic feeding into a maxnum can produce inconsistent results. For example,
-`maxnum(fadd(sNaN, -0.0), 1.0)` can produce qNaN or 1.0 depending on whether `fadd` is folded.
+``maxnum(fadd(sNaN, -0.0), 1.0)`` can produce qNaN or 1.0 depending on whether ``fadd`` is folded.
IEEE-754-2008 defines maxNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
defines :ref:`maximumNumber <llvm-maximumnum-intrinsic>`.
@@ -16801,9 +16801,9 @@ and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
Some architectures, such as ARMv8 (FMAXNM), LoongArch (fmax), MIPSr6 (max.fmt), PowerPC/VSX (xsmaxdp),
have instructions that match these semantics exactly; thus it is quite simple for these architectures.
-Some architectures have similiar ones while they are not exact equivalent. Such as x86 implements `MAXPS`,
-which implements the semantics of C code `a>b?a:b`: NUM vs qNaN always return qNaN. `MAXPS` can be used
-if `nsz` and `nnan` are given.
+Some architectures have similiar ones while they are not exact equivalent. Such as x86 implements ``MAXPS``,
+which implements the semantics of C code ``a>b?a:b``: NUM vs qNaN always return qNaN. ``MAXPS`` can be used
+if ``nsz`` and ``nnan`` are given.
For existing libc implementations, the behaviors of fmin may be quite different on sNaN and signed zero behaviors,
even in the same release of a single libm implemention.
>From 24684c1ea08cd6b6e932b4bb466b64e50c9b7970 Mon Sep 17 00:00:00 2001
From: YunQiang Su <yunqiang at isrc.iscas.ac.cn>
Date: Fri, 24 Jan 2025 18:37:30 +0800
Subject: [PATCH 18/18] Fix link
---
llvm/docs/LangRef.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index f4c1cd36546766..5c52ce2986a05b 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -16734,7 +16734,7 @@ so arithmetic feeding into a minnum can produce inconsistent results. For exampl
``minnum(fadd(sNaN, -0.0), 1.0)`` can produce qNaN or 1.0 depending on whether ``fadd`` is folded.
IEEE-754-2008 defines minNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
-defines :ref:`minimumNumber <llvm-minimumnum-intrinsic>`.
+defines :ref:`minimumNumber <i_minimumnum>`.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of ``minnum(-0.0, +0.0)`` may be either -0.0 or +0.0.
@@ -16794,7 +16794,7 @@ so arithmetic feeding into a maxnum can produce inconsistent results. For exampl
``maxnum(fadd(sNaN, -0.0), 1.0)`` can produce qNaN or 1.0 depending on whether ``fadd`` is folded.
IEEE-754-2008 defines maxNum, and it was removed in IEEE-754-2019. As the replacement, IEEE-754-2019
-defines :ref:`maximumNumber <llvm-maximumnum-intrinsic>`.
+defines :ref:`maximumNumber <i_maximumnum>`.
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C
and IEEE-754-2008: the result of maxnum(-0.0, +0.0) may be either -0.0 or +0.0.
More information about the llvm-commits
mailing list