Because stdarch has a really large number of unsafe functions with
single-line calls, `unsafe_op_in_unsafe_fn` would end up adding a lot of
noise, so for now we will allow it to migrate to 2024.
Naming right now for wasm simd intrinsics takes the signededness of the
instruction into account, but some operations are the same regardless of
signededness, such as `i32x4_add`. This commit adds aliases for all of
these operations under unsigned names as well (such as `u32x4_add`)
which are just a `pub use` to rename the item as two names. The goal of
this is to assist in reading code (no need to switch back and forth
between `i` and `u`) as well as writing code (no need to always remember
which operations are the same for signed/unsigned but only available
under the signed names).
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.
This commit:
* renames `coresimd` to `core_arch` and `stdsimd` to `std_detect`
* `std_detect` does no longer depend on `core_arch` - it is a freestanding
`no_std` library that only depends on `core` - it is renamed to `std_detect`
* moves the top-level coresimd and stdsimd directories into the appropriate
crates/... directories - this simplifies creating crate.io releases of these crates
* moves the top-level `coresimd` and `stdsimd` sub-directories into their
corresponding crates in `crates/{core_arch, std_detect}`.
This commit switches CI to running `rustfmt` on the stable compiler (as
rustfmt is stable now!). Additionally it deletes `rustfmt.toml` to
ensure we're following the same style as the rest of the ecosystem.
* fix build after stabilization of cfg_target_feature and target_feature
* fix doc tests
* fix spurious unused_attributes warning
* fix more unused attribute warnings
* More unnecessary target features
* Remove no longer needed trait imports
* Remove fixed upstream workarounds
* Fix parsing the #[assert_instr] macro
Following upstream proc_macro changes
* Fix form and parsing of #[simd_test]
* Don't use Cargo features for testing modes
Instead use RUSTFLAGS with `--cfg`. This'll help us be compatible with the
latest Cargo where a tweak to workspaces and features made the previous
invocations we had invalid.
* Don't thread RUSTFLAGS through docker
* Re-gate on x86 verification
Closes#411
This commit renames the `is_target_feature_detected!` macro to have different
names depending on the platform. For example:
* `is_x86_feature_detected!`
* `is_arm_feature_detected!`
* `is_aarch64_feature_detected!`
* `is_powerpc64_feature_detected!`
Each macro already has a platform-specific albeit similar interface. Currently,
though, each macro takes a different set of strings so the hope is that like
with the name of the architecture in the module we can signal the dangers of
using the macro in a platform-agnostic context.
One liberty taken with the macro currently though is to on both the x86 and
x86_64 architectures name the macro `is_x86_feature_detected` rather than also
having an `is_x86_64_feature_detected`. This mirrors, however, how all the
intrinsics are named the same on x86/x86_64.
* Prepare portable packed SIMD vector types for RFCs
This commit cleans up the implementation of the Portable Packed Vector Types
(PPTV), adds some new features, and makes some breaking changes.
The implementation is moved to `coresimd/src/ppvt` (they are
still exposed via `coresimd::simd`).
As before, the vector types of a certain width are implemented in the `v{width}`
submodules. The `macros.rs` file has been rewritten as an `api` module that
exposes the macros to implement each API.
It should now hopefully be really clear where each API is implemented, and which types
implement these APIs. It should also now be really clear which APIs are tested and how.
- boolean vectors of the form `b{element_size}x{number_of_lanes}`.
- reductions: arithmetic, bitwise, min/max, and boolean - only the facade,
and a naive working implementation. These need to be implemented
as `llvm.experimental.vector.reduction.{...}` but this needs rustc support first.
- FromBits trait analogous to `{f32,f64}::from_bits` that perform "safe" transmutes.
Instead of writing `From::from`/`x.into()` (see below for breaking changes) now you write
`FromBits::from_bits`/`x.into_bits()`.
- portable vector types implement `Default` and `Hash`
- tests for all portable vector types and all portable operations (~2000 new tests).
- (hopefully) comprehensive implementation of bitwise transmutes and lane-wise
casts (before `From` and the `.as_...` methods where implemented "when they were needed".
- documentation for PPTV (not great yet, but better than nothing)
- conversions/transmutes from/to x86 architecture specific vector types
- `store/load` API has been replaced with `{store,load}_{aligned,unaligned}`
- `eq,ne,lt,le,gt,ge` APIs now return boolean vectors
- The `.as_{...}` methods have been removed. Lane-wise casts are now performed by `From`.
- `From` now perform casts (see above). It used to perform bitwise transmutes.
- `simd` vectors' `replace` method's result is now `#[must_use]`.
* enable backtrace and nocapture
* unalign load/store fail test by 1 byte
* update arm and aarch64 neon modules
* fix arm example
* fmt
* clippy and read example that rustfmt swallowed
* reductions should take self
* rename add/mul -> sum/product; delete other arith reductions
* clean up fmt::LowerHex impl
* revert incorret doc change
* make Hash equivalent to [T; lanes()]
* use travis_wait to increase timeout limit to 20 minutes
* remove travis_wait; did not help
* implement reductions on top of the llvm.experimental.vector.reduction intrinsics
* implement cmp for boolean vectors
* add missing eq impl file
* implement default
* rename llvm intrinsics
* fix aarch64 example error
* replace #[inline(always)] with #[inline]
* remove cargo clean from run.sh
* workaround broken product in aarch64
* make boolean vector constructors const fn
* fix more reductions on aarch64
* fix min/max reductions on aarch64
* remove whitespace
* remove all boolean vector types except for b8xN
* use a sum reduction fallback on aarch64
* disable llvm add reduction for aarch64
* rename the llvm intrinsics to use llvm names
* remove old macros.rs file
With RFC 2325 looking close to being accepted, I took a crack at
reorganizing this repository to being more amenable for inclusion in
libstd/libcore. My current plan is to add stdsimd as a submodule in
rust-lang/rust and then use `#[path]` to include the modules directly
into libstd/libcore.
Before this commit, however, the source code of coresimd/stdsimd
themselves were not quite ready for this. Imports wouldn't compile for
one reason or another, and the organization was also different than the
RFC itself!
In addition to moving a lot of files around, this commit has the
following major changes:
* The `cfg_feature_enabled!` macro is now renamed to
`is_target_feature_detected!`
* The `vendor` module is now called `arch`.
* Under the `arch` module is a suite of modules like `x86`, `x86_64`,
etc. One per `cfg!(target_arch)`.
* The `is_target_feature_detected!` macro was removed from coresimd.
Unfortunately libcore has no ability to export unstable macros, so for
now all feature detection is canonicalized in stdsimd.
The `coresimd` and `stdsimd` crates have been updated to the planned
organization in RFC 2325 as well. The runtime bits saw the largest
amount of refactoring, seeing a good deal of simplification without the
core/std split.
* add runtime detection for aes-ni
* fmtting and fixing some clippy issues
* add runtime-feature detection for tsc
* fix remaining clippy issues
* manually fix some formatting issues
* increase feature cache size
* use 2x AtomicU32 on 32-bit targets as the feature cache
* use the new cache in stdsimd
