Don't propagate NaN for {f32,f64}::{min,max}

[bjorn3]

libstd docs for {f32,f64}::{min,max}:

If one of the arguments is NaN, then the other argument is returned.

Blocked on bytecodealliance/wasmtime#1906

[eggyal]

There's not just the matter of NaN propagation (which is documented), but also how -0.0 and +0.0 are compared (which is not): on this point, the llvm.minnum instructions currently used by cg_llvm mirror Cranelift's fmin_pseudo instruction, rather than the fmin instruction that's currently adopted by cg_clif.

cg_clif's existing behaviour appears to follow IEEE754, whereas the current behaviour of rust+llvm (including the documented treatment of NaNs) does not. See rust-lang/rust#83984

[sunfishcode]

Rust+llvm are following the family of functions known in IEEE 754-2008 as minNum which prefer a number over a NaN and don't define what happens between -0.0 and +0.0 (and has surprising behavior on sNaN).

Cranelift's fmin follows IEEE 754-2019's new minimum and WebAssembly's min, which prefer a NaN over a number and treat -0.0 as less than +0.0 (and have unsurprising behavior on sNaN).

IEEE 754-2019 also defines minimumNumber, which prefers a number over a NaN and treats -0.0 as less than +0.0 (and has unsurprising behavior on sNaN). WebAssembly's MVP was designed before IEEE 754-2019's direction on this issue was known, so it didn't originally add operators for minimumNumber and maximumNumber. Now that IEEE 754-2019 is published, it's a reasonable assumption that WebAssembly should eventually add operators for these.