Lots of time and lots of things have happened since the simd128 support
was first added to this crate. Things are starting to settle down now so
this commit syncs the Rust intrinsic definitions with the current
specification (https://github.com/WebAssembly/simd). Unfortuantely not
everything can be enabled just yet but everything is in the pipeline for
getting enabled soon.
This commit also applies a major revamp to how intrinsics are tested.
The intention is that the setup should be much more lightweight and/or
easy to work with after this commit.
At a high-level, the changes here are:
* Testing with node.js and `#[wasm_bindgen]` has been removed. Instead
intrinsics are tested with Wasmtime which has a nearly complete
implementation of the SIMD spec (and soon fully complete!)
* Testing is switched to `wasm32-wasi` to make idiomatic Rust bits a bit
easier to work with (e.g. `panic!)`
* Testing of this crate's simd128 feature for wasm is re-enabled. This
will run on CI and both compile and execute intrinsics. This should
bring wasm intrinsics to the same level of parity as x86 intrinsics,
for example.
* New wasm intrinsics have been added:
* `iNNxMM_loadAxA_{s,u}`
* `vNNxMM_load_splat`
* `v8x16_swizzle`
* `v128_andnot`
* `iNNxMM_abs`
* `iNNxMM_narrow_*_{u,s}`
* `iNNxMM_bitmask` - commented out until LLVM is updated to LLVM 11
* `iNNxMM_widen_*_{u,s}` - commented out until
bytecodealliance/wasmtime#1994 lands
* `iNNxMM_{max,min}_{u,s}`
* `iNNxMM_avgr_u`
* Some wasm intrinsics have been removed:
* `i64x2_trunc_*`
* `f64x2_convert_*`
* `i8x16_mul`
* The `v8x16.shuffle` instruction is exposed. This is done through a
`macro` (not `macro_rules!`, but `macro`). This is intended to be
somewhat experimental and unstable until we decide otherwise. This
instruction has 16 immediate-mode expressions and is as a result
unsuited to the existing `constify_*` logic of this crate. I'm hoping
that we can game out over time what a macro might look like and/or
look for better solutions. For now, though, what's implemented is the
first of its kind in this crate (an architecture-specific macro), so
some extra scrutiny looking at it would be appreciated.
* Lots of `assert_instr` annotations have been fixed for wasm.
* All wasm simd128 tests are uncommented and passing now.
This is still missing tests for new intrinsics and it's also missing
tests for various corner cases. I hope to get to those later as the
upstream spec itself gets closer to stabilization.
In the meantime, however, I went ahead and updated the `hex.rs` example
with a wasm implementation using intrinsics. With it I got some very
impressive speedups using Wasmtime:
test benches::large_default ... bench: 213,961 ns/iter (+/- 5,108) = 4900 MB/s
test benches::large_fallback ... bench: 3,108,434 ns/iter (+/- 75,730) = 337 MB/s
test benches::small_default ... bench: 52 ns/iter (+/- 0) = 2250 MB/s
test benches::small_fallback ... bench: 358 ns/iter (+/- 0) = 326 MB/s
or otherwise using Wasmtime hex encoding using SIMD is 15x faster on 1MB
chunks or 7x faster on small <128byte chunks.
All of these intrinsics are still unstable and will continue to be so
presumably until the simd proposal in wasm itself progresses to a later
stage. Additionaly we'll still want to sync with clang on intrinsic
names (or decide not to) at some point in the future.
* wasm: Unconditionally expose SIMD functions
This commit unconditionally exposes SIMD functions from the `wasm32`
module. This is done in such a way that the standard library does not
need to be recompiled to access SIMD intrinsics and use them. This,
hopefully, is the long-term story for SIMD in WebAssembly in Rust.
It's unlikely that all WebAssembly runtimes will end up implementing
SIMD so the standard library is unlikely to use SIMD any time soon, but
we want to make sure it's easily available to folks! This commit enables
all this by ensuring that SIMD is available to the standard library,
regardless of compilation flags.
This'll come with the same caveats as x86 support, where it doesn't make
sense to call these functions unless you're enabling simd support one
way or another locally. Additionally, as with x86, if you don't call
these functions then the instructions won't show up in your binary.
While I was here I went ahead and expanded the WebAssembly-specific
documentation for the wasm32 module as well, ensuring that the current
state of SIMD/Atomics are documented.
* Update Intel intrinsics definitions with the latest version
* Update _mm256_extract_epi{8,16} to match latest definition
* Fix _mm_extract_epi16 sign extension
Fixes#867
Building the MIPS MSA module for non-fp64 targets fails with an LLVM
error. This commit blacklists PSP targets from MSA support in order to
fix building libcore.
* Manually preserve rbx across cpuid instruction
This fixes an issue observed when using __cpuid and __cpuid_count with
Address Sanitizer enabled: the generated code uses the rbx register to
access ASAN tracking information without reloading it after cpuid,
resulting in a segfault since the rbx register is overwritten by cpuid
(https://crbug.com/1072045).
This seems like a compiler backend bug, and indeed there is a
long-standing LLVM bug report about a very similar issue:
https://bugs.llvm.org/show_bug.cgi?id=17907
To work around this issue, we can manually preserve the rbx register
contents in the inline assembly. This is the approach taken by LLVM's
own host cpuid detection code (lib/Host/Support.cpp). The original rbx
value is stashed in rsi, which is then swapped with rbx to restore the
original value as well as keep the output ebx value from the CPUID
instruction to be used as an output of the inline assembly.
The rbx clobber is also removed; this seems ineffective, and it
conflicts with the ebx output of the inline assembly (ebx is a
subregister of rbx): "Note that clobbering named registers that are also
present in output constraints is not legal."
(https://llvm.org/docs/LangRef.html#clobber-constraints)
* Add link to LLVM bug in cpuid workaround comment
error[E0432]: unresolved import `self::arm::check_for`
--> src/libstd/../stdarch/crates/std_detect/src/detect/os/freebsd/mod.rs:11:17
|
11 | pub use self::arm::check_for;
| ^^^^^^^^^^^^^^^^^^^^ no `check_for` in `std_detect::detect::os::arm`
error[E0425]: cannot find value `detect_features` in module `self::os`
--> src/libstd/../stdarch/crates/std_detect/src/detect/mod.rs:121:37
|
121 | cache::test(x as u32, self::os::detect_features)
| ^^^^^^^^^^^^^^^ not found in `self::os`
|
help: possible candidate is found in another module, you can import it into scope
|
20 | use crate::std_detect::detect::os::arm::detect_features;
* re-stabilize the AVX-512 features that were stabilized in Rust 1.27.0
https://github.com/rust-lang/stdarch/pull/739 added per-feature
stabilization of runtime CPU feature detection. In so doing, it
de-stabilized some detection features that had been stable since Rust
1.27.0, breaking some published crates (on nightly). This commit
re-stabilizes the subset of AVX-512 detection features that were
included in 1.27.0 (that is, the pre-Ice-Lake subset). Other instruction
sets (MMX in particular) remain de-stabilized, pending a decision about
whether should ever stabilize them.
See https://github.com/rust-lang/rust/issues/68905.
* add a comment explaining feature detection stability
* adjust stabilizations to match most recent proposal
https://github.com/rust-lang/rust/issues/68905#issuecomment-595376319
* Fix race condition in feature cache on 32 platforms
If we observe that the second word is initialized, we can't really
assume that the first is initialized as well. So check each word
separately.
* Use stronger atomic ordering
Better SeqCst than sorry!
* Use two caches on x64 for simplicity
