Use of simd_reduce_max/min for floats is suspicious

[RalfJung]

Some aarch64 vendor intrinsics seem to be implemented via simd_reduce_max/simd_reduce_min on float types (Cc @folkertdev). Is that truly the right thing to do? We currently codegen these to llvm.vector.reduce.fmax.*, which is documented to have the same semantics as llvm.maxnum, but the situation around the documented and actual semantics of these operations is extraordinarily messy at the moment. Our own documentation for the intrinsic disagrees with the LLVM documentation, and Miri implements yet another variant of these semantics.

• LLVM docs: SNaN behavior from IEEE-754-2008, signed zeros from IEEE-754-2019 (i.e. -0.0 < +0.0)
• LLVM implementation: ? (on x86, LLVM does not actually implement the documented behavior, but for stdarch we only care about aarch64)
• Rust intrinsic docs: everything like IEEE-754-2008
• Miri: SNaN from IEEE-754-2019, signed zeros from IEEE-754-2008 (i.e., non-deterministic)

As a start, it would be good to figure out the exact intended semantics wrt SNaN and signed zeros for aarch64 vmaxnmvq_f32 and friends. But we also have to take into account that simd_reduce_max/simd_reduce_min are meant to be portable, so designing their semantics around the aarch64 behavior is likely not the right call. By default, I would expect them to behave like f*::max, which is what Miri implements.

(I did not find any use of simd_reduce_max/simd_reduce_min for float types for other targets, but I may have missed some.)

[folkertdev]

https://developer.arm.com/architectures/instruction-sets/intrinsics/vmaxnmvq_f32 only mentions that it reduces using the maximum.

Then looking at documentation for maximum operations, e.g. https://developer.arm.com/architectures/instruction-sets/intrinsics/vmaxnmq_f32 it says nothing but links to the instruction https://developer.arm.com/documentation/ddi0602/2025-06/SIMD-FP-Instructions/FMAXNM--vector---Floating-point-maximum-number--vector--

Regardless of the value of FPCR.AH, the behavior is as follows:

• Negative zero compares less than positive zero.
• If one element is numeric and the other is a quiet NaN, the result is the numeric value.
• When FPCR.DN is 0, if either element is a signaling NaN or if both elements are NaNs, the result is a quiet NaN.
• When FPCR.DN is 1, if either element is a signaling NaN or if both elements are NaNs, the result is Default NaN.

---

(I did not find any use of simd_reduce_max/simd_reduce_min for float types for other targets, but I may have missed some.)

No I think that's right, we've been careful with using them given the subtlety of this operation

[RalfJung]

Okay so what aarch64 wants for these operations is the SNaN behavior from IEEE-754-2008 and the signed zeros from IEEE-754-2019. That's what LLVM currently documents for llvm.vector.reduce.fmax, but the situation is volatile. Also, it's far from clear that that's really the semantics we want for our non-target-specific intrinsic.

[folkertdev]

An additional complication is that we do want our portable intrinsic to optimize well, so ideally it would actually map to the instruction that the hardware has. We verify that the intrinsic optimizes to the instruction.

[RalfJung]

If we define the portable intrinsic in a target-independent way that optimizes well, that means we have to make it pretty non-deterministic, and that means we cannot use it for stdarch because there we want deterministic behavior.

[RalfJung]

Generally, the semantics of the simd_* intrinsics has been driven by the portable-simd effort. portable-simd is not very precise about the exact intended semantics of min/max, but I think it is safe to assume that it is meant to be consistent with $float::min/max.

So IMO we should

• stop using simd_reduce_max/min for aarch64 float intrinsics
• document simd_reduce_max/min to have the same semantics as $float::min/max

Cc @workingjubilee @calebzulawski