[clang] [llvm] Intrinsic: introduce minimumnum and maximumnum (PR #93841)

[Joshua Cranmer via cfe-commits]

================
@@ -15883,6 +15883,95 @@ The returned value is completely identical to the input except for the sign bit;
 in particular, if the input is a NaN, then the quiet/signaling bit and payload
 are perfectly preserved.
 
+.. _i_fminmax_family:
+
+'``llvm.min.*``' Intrinsics Comparation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Standard:
+"""""""""
+
+IEEE754 and ISO C define some min/max operations, and they have some differences
+on working with qNaN/sNaN and +0.0/-0.0. Here is the list:
+
+.. list-table::
+   :header-rows: 2
+
+   * - ``ISO C``
+     - fmin/fmax
+     - none
+     - fmininum/fmaximum
+     - fminimum_num/fmaximum_num
+
+   * - ``IEEE754``
+     - none
+     - nimNUM/maxNUM (2008)
+     - minimum/maximum (2019)
+     - minimumNumber/maximumNumber (2019)
+
+   * - ``+0.0 vs -0.0``
+     - either one
+     - +0.0 > -0.0
----------------
jcranmer-intel wrote:

My copy of IEEE 754-2008 says of minNum:

> minNum(x, y) is the canonicalized number x if x<y, y if y<x, the canonicalized number if one
operand is a number and the other a quiet NaN. Otherwise it is either x or y, canonicalized (this
means results might differ among implementations). 

IEEE 754 doesn't guarantee the sign of `minNum(-0.0, +0.0)`, just like `fmin`.

Note also that TS 18611-1 bound C `fmin` to IEEE 754-2008 `minNum` (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1711.pdf)--`fmin` and `minNum` should also be considered equivalent.

(Also, while I'm being pedantic, the spelling used in IEEE 754 is `minNum`, not `minNUM`.

https://github.com/llvm/llvm-project/pull/93841