simd_fmin/fmax: make semantics and name consistent with scalar intrinsics
This is the SIMD version of https://github.com/rust-lang/rust/pull/153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added.
In terms of providers of this API:
- Miri, GCC, and cranelift already implement the new semantics, so no changes are needed.
- LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics.
In terms of consumers of this API:
- Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here.
- Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (https://github.com/rust-lang/stdarch/issues/2056).
Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`?
Also see https://github.com/rust-lang/rust/issues/153395.
- Note that working directory matters
- Note that stdarch-gen-arm uses nightly
- Fix missing directory. Without this, it would print to stdout in one
giant merged file.
ci is showing a lot of warnings (72) right now. apparently
actions/checkout@v4 uses Node.js 20, and all github actions are
scheduled to be force opted-in to Node.js 24 on 2026-06-02.
I don't anticipate bumping the checkout action to v6 / Node.js 24
to cause any issues (Node.js 24 drops support for ARM32 and macOS
versions <= 13.4, but this shouldn't matter because we use Docker
to test in those environments, not github runners natively) but if
it does cause issues it's probably better to find out now rather
than by surprise 3 months from now... :)
Folkert de Vries