llvm.minnum should be lowered to fminimum_numf instead of fminf

[wzssyqa]

In https://llvm.org/docs/LangRef.html#llvm-minnum-intrinsic

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

While in https://www.gnu.org/software/libc/manual/html_node/Misc-FP-Arithmetic.html

If an argument is a quiet NaN, the other argument is returned. If both arguments are NaN, or either is a signaling NaN, NaN is returned.

[wzssyqa]

define float @mins(float %x, float %y) {
   %r = tail call float @llvm.minnum.f32(float %x, float %y)
   ret float %r
 }

Glibc introduce fminimum_numf since 2021. It may be a trouble.

[dtcxzyw]

cc @arsenm @andykaylor @jcranmer-intel

[arsenm]

Did the glibc behavior also change for fmin/fmax? I remember testing this long ago.

LLVM doesn't pretend to handling signaling nans correctly for non-strictfp functions. We also should rename the minnum/maxnum intrinsics; the name was always wrong. We should instead have something like minnum2019, minnum2008, and fmin for the range of behaviors

[wzssyqa]

Did the glibc behavior also change for fmin/fmax? I remember testing this long ago.

Ohh, yes, it does.
https://sourceware.org/git/?p=glibc.git;a=commit;h=90f0ac10a74b2d43b5a65aab4be40565e359be43
I guess it's due to C23 changes:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
Page 270

LLVM doesn't pretend to handling signaling nans correctly for non-strictfp functions. We also should rename the minnum/maxnum intrinsics; the name was always wrong. We should instead have something like minnum2019, minnum2008, and fmin for the range of behaviors

I guess that we should fellow the naming scheme with IEEE754, if we'd like to support the same behavior of IEEE.
In 2008, it has minNUM, which cares about sNaN;
In 2019, it has minimumNUM introduced, and minNUM is dropped.

If we try to support our flavor operations, I think that we should use a quite different naming scheme, such as
fmin_num
etc.

[wzssyqa]

Ohh, maybe we should update the documents of [‘llvm.minnum.*’ Intrinsic](https://llvm.org/docs/LangRef.html#id2157)
and drop

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

I guess this claims existed due to that the fmin(3) had this behavior before C2X.

[arsenm]

Did the glibc behavior also change for fmin/fmax? I remember testing this long ago.

Ohh, yes, it does. https://sourceware.org/git/?p=glibc.git;a=commit;h=90f0ac10a74b2d43b5a65aab4be40565e359be43 I guess it's due to C23 changes: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf Page 270

fminimum and fmaximum are new and separate operations. They are not a change to the behavior of fmin/fmax. Do you have a reference to a change in the fmin implementation, specifically?

LLVM doesn't pretend to handling signaling nans correctly for non-strictfp functions. We also should rename the minnum/maxnum intrinsics; the name was always wrong. We should instead have something like minnum2019, minnum2008, and fmin for the range of behaviors

I guess that we should fellow the naming scheme with IEEE754, if we'd like to support the same behavior of IEEE. In 2008, it has minNUM, which cares about sNaN; In 2019, it has minimumNUM introduced, and minNUM is dropped.

It's not dropped, it's now called minimumNumber which coexists with minimum. It is stronger than the 2008 definition since it definitively orders -0 as less than +0

[wzssyqa]

Did the glibc behavior also change for fmin/fmax? I remember testing this long ago.

Ohh, yes, it does. https://sourceware.org/git/?p=glibc.git;a=commit;h=90f0ac10a74b2d43b5a65aab4be40565e359be43 I guess it's due to C23 changes: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf Page 270

fminimum and fmaximum are new and separate operations. They are not a change to the behavior of fmin/fmax. Do you have a reference to a change in the fmin implementation, specifically?

https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=manual/arith.texi;h=edb9cfdafbd3119bf785802b0bcfb58f28590cf5;hp=6a158e624d8f48c8290e527efd5a4dcf09c6d7ac;hb=90f0ac10a74b2d43b5a65aab4be40565e359be43;hpb=5bf07e1b3a74232bfb8332275110be1a5da50f83

It's in the diff of manual/arith.texi.
Or maybe it is just a documentation update.

[arsenm]

https://godbolt.org/z/z7WG3q3Gq glibc does seem to be following the IEEE sNaN behavior. On MacOS, it does not and treats the snan the same as nan.

[wzssyqa]

So, my proposal is to emit fminimum_numf if we are using -std=gnu23/c23.

#93159

[wzssyqa]

It's not dropped, it's now called minimumNumber which coexists with minimum. It is stronger than the 2008 definition since it definitively orders -0 as less than +0

In the documentation of IEEE754-2019, there is:

NOTE — The minNum and maxNum operations of the 2008 version of the standard have been replaced by
the recommended operations of 9.6.

And there is no other talking about minNum or maxNum.

[arsenm]

NOTE — The minNum and maxNum operations of the 2008 version of the standard have been replaced by
the recommended operations of 9.6.

If you actually look at 9.6, it has this: 9.6 Minimum and maximum operations 9.6.0, which lists minimum, minimumNumber, maximum, and maximumNumber. So yes, "minNum" was removed and replaced with "minimum" and "minimumNumber"

So mostly this is a question of wrangling the behavior of different implementations. The LangRef and some of the lowerings will need to change. The LangRef behavior as written matches the behavior on macOS. The apparent glibc behavior on x86 matches the IEEE sNaN handling. So some combination of the lowering and the LangRef will need to change.

The AArch64 ISA documentation isn't enlightening me on the instruction behavior there.

Additionally, OpenCL says "fmin and fmax behave as defined by C99 and may not match the IEEE 754-2008 definition for minNum and maxNum with regard to signaling NaNs. Specifically, signaling NaNs may behave as quiet NaNs."

I would be happy if we could get the minnum behavior to match the IEEE 2019 behavior, matching the sNaN behavior and also strengthening the signed 0 assumption. The outlier lowerings would then have to adjust