What are the intended semantics for simd_fmin/fmax and simd_reduce_min/max vs signaling NaN?

[RalfJung]

After a bunch of discussion, the intended semantics of min/max on scalar floats have been clarified to be exactly what we have documented for years already: they behave like the IEEE 754-2019 min/maximumNumber operation, except that signed zeros are ordered non-deterministically. (Equivalently: they behave like IEEE 754-2008 min/maxNum except that when one input is a signed NaN and the other is a number, the number is returned.) This corresponds to llvm.min/maximumnum nsz in LLVM (as clarified by llvm/llvm-project#172012). #153343 fixes codegen to actually implement those semantics.

For SIMD, we have a bunch of intrinsics where the same question arises: simd_fmin and simd_fmax as well as simd_reduce_min and simd_reduce_max which also support floats. They are documented to use "IEEE-754 maxNum", which I presume refers to the IEEE 754-2008 operation. This is strangely inconsistent with the scalar operation we expose. It is also not what const-eval and Miri do; they implement the same semantics for SIMD min/max as they do for scalar min/max. The only difference is in the behavior for signaling NaNs, which apparently none of the test suites are covering. But obviously, Miri having different behavior than rustc is bad.

So... should we change the SIMD intrinsics to match what the scalar operations do? I think we should. However, LLVM does not currently seem to have a version of llvm.vector.reduce.* that uses min/maximumnum semantics (Cc @nikic), so currently it's tricky to implement this correctly. Also, we have to be careful about stdarch using these intrinsics to implement vendor intrinsics -- there are some uses of all of these intrinsics in stdarch (Cc @folkertdev @Amanieu ). This also affects portable-simd but since that is unstable that seems fine, and AFAIK there the design goal generally is to match the scalar standard library (Cc @workingjubilee @calebzulawski ).

[Amanieu]

It would probably be useful to expose all the different variants of min/max as intrinsics so that stdarch can select the appropriate one for various platform-specific intrinsics. Specifically we would want:

• 2019 minimumNumber without nsz for RISC-V
• 2008 minNum without nsz for ARM.
• minimum/maximum without nsz for ARM.

I think we should just have intrinsics for the full set of {minimum, minNum, minimumNumber} x {with nsz, without nsz}. Whether we expose those in the public API is a separate matter.

[RalfJung]

I think we should just have intrinsics for the full set of {minimum, minNum, minimumNumber} x {with nsz, without nsz}.

That's 6 variants for 4 intrinsics, making it 24 intrinsics total. I don't think that's worth it.

stdarch can only really use simd_* intrinsics when there's consistent behavior across targets and LLVM provides a "portable" intrinsic for that. If we end up with as many intrinsics as we have targets, we gained nothing over directly calling LLVM operations from stdarch.

2008 minNum without nsz for ARM.

Note that simd_fmin/fmax as currently documented do have the nsz behavior: IEEE 754-2008 says that signed zero behavior is non-deterministic. So stdarch using those operations is already sketchy.

Also note that LLVM's minnum without nsz still has non-determinism: when one input is an SNaN, the result may be a NaN or the other input. I doubt that's the behavior you want for ARM. So I don't think minnum can ever be used for any stdarch intrinsic.

[sayantn]

We can use a const enum parameter to select which variant of simd_fmax you want, that'll reduce the number of distinct intrinsic needed.

[RalfJung]

We could, but that's still a lot of boilerplate and I don't see the point of doing that. When behavior differs across targets, we typically use target-specific intrinsics in stdarch; we do not try to add enough intrinsics so that every target's behavior can be directly accessed on all targets.

[RalfJung]

Also, as already mentioned above, none of the LLVM intrinsics is actually suitable for targets which guarantee that SNaN inputs lead to SNaN outputs but QNaN inputs return the other input if that is a number -- and I assume ARM guarantees that. LLVM is always permitted to treat an SNaN as if it was a QNaN. So, even with a whole family of intrinsics, it'd still be wrong to use them to encode ARM vendor intrinsics, unless we're willing to have the intrinsics diverge from the actual instruction like this.

(FWIW, using the intrinsics always diverges from the actual instruction when NaNs are returned. The SIMD intrinsics are subject to our usual NaN rules. But that just affects the sign and payload of a NaN, not whether a NaN is returned in the first place, so that may be an acceptable tradeoff for stdarch intrinsics.)