Further align the semantics of minimum and maximum with IEEE-754-2019.
From Section 6.2.3,
An operation that propagates a NaN operand to its result and has a single NaN as an input should produce a NaN with the payload of the input NaN if representable in the destination format. `If two or more inputs are NaN, then the payload of the resulting NaN should be identical to the payload of one of the input NaNs if representable in the destination format. This standard does not specify which of the input NaNs will provide the payload.
This will enable us to, in some specific circumstances, to combine fcmp -> select into an intrinsic, just as what has been done for integer operations.
But do these semantics work for all our backends that use them?
For AArch64, I think this is okay for both scalar, NEON and SVE (although the textual SVE description looks like it has a bug in it, it shares the same pseudo code).
For WebAssembly, this aligns with propagating a canonical NaN but otherwise the return value is picked non-deterministically. Is it okay that LLVM IR is stricter in this case?
I haven't looked at other ISAs...
Requiring the output NaN to be one of the input NaNs is stronger than what IEEE 754 requires (it describes NaN propagation as a recommendation but not as a requirement). And, it prevents implementing these intrinsics efficiently on ARM CPUs configured for Default NaN mode, RISC-V (as far I can tell from the manual), and Wasm.