Guillaume Gomez
67ab3ac423
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.
core::arch - Rust's core library architecture-specific intrinsics
The core::arch module implements architecture-dependent intrinsics (e.g. SIMD).
Usage
core::arch is available as part of libcore and it is re-exported by
libstd. Prefer using it via core::arch or std::arch than via this crate.
Using core::arch via this crate requires nightly Rust, and it can (and does)
break often. The only cases in which you should consider using it via this crate
are:
-
if you need to re-compile
core::archyourself, e.g., with particular target-features enabled that are not enabled forlibcore/libstd. Note: if you need to re-compile it for a non-standard target, please prefer usingxargoand re-compilinglibcore/libstdas appropriate instead of using this crate. -
using some features that might not be available even behind unstable Rust features. We try to keep these to a minimum. If you need to use some of these features, please open an issue so that we can expose them in nightly Rust and you can use them from there.
Documentation
- Documentation - i686
- Documentation - x86_64
- Documentation - arm
- Documentation - aarch64
- Documentation - powerpc
- Documentation - powerpc64
- How to get started
- How to help implement intrinsics
License
core_arch is primarily distributed under the terms of both the MIT license and
the Apache License (Version 2.0), with portions covered by various BSD-like
licenses.
See LICENSE-APACHE, and LICENSE-MIT for details.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in core_arch by you, as defined in the Apache-2.0 license,
shall be dual licensed as above, without any additional terms or conditions.