================ @@ -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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
