[llvm] [X86] Lower `minimum`/`maximum`/`minimumnum`/`maximumnum` using bitwise operations (PR #170069)

[via llvm-commits]

valadaptive wrote:

> * AVX-512 has `VRANGEPS` which despite it's name computes "minimumnum"/"maximumnum" like IEEE 2008.

`VRANGEPS` *does* handle signed zeroes properly, but IEEE754-2008 semantics are not what we want here. If one argument is a *signaling* NaN, `VRANGEPS` and the IEEE754-2008 operations both return a quiet NaN, but we want to return the non-NaN operand no matter what. On AArch64, where the `FMINNM` and `FMAXNM` instructions also implement IEEE754-2008, I believe we insert some "canonicalize" operations on the inputs to quiet any NaNs. We could do something similar here, but that's best left for a future PR.

> * I think `minimum` can be implemented like `minimum(x,y) = minps(x,y)|minps(y,x)`. If one of x or y is NaN, then one of the two will be NaN and so will be the result. If both are not NaN or zero, then they agree and hence the "or" is the "minps". Finally, if both are zero, then `minps(x,y)|minps(y,x)=y|x` which prefers the signed zero.

Indeed, this is [what Cranelift does](https://github.com/bytecodealliance/wasmtime/blob/fee9be219e300fa40e9f79b7650f22db401a8f27/cranelift/codegen/src/isa/x64/lower.isle#L2746-L2758). I'd have to check how it performs against the bitwise approach. They insert a bunch of extra operations to ensure the result is a quiet NaN, which LLVM doesn't care about.

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