I am not certain why some crates are missing - it might be by accident or on purpose, so feel free to reject. This makes sure no crate is missed by accident,
and also removed the non-existent `wasm-assert-instr-tests` crate.
P.S. Also, added some crate-level lints, but perhaps these should be added to all crates in the workspace?
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}`.
* Add wasm32 simd128 intrinsics
* test wasm32 simd128 instructions
* Run wasm tests like all other tests
* use modules instead of types to access wasm simd128 interpretations
* generate docs for wasm32-unknown-unknown
* fix typo
* Enable #[assert_instr] on wasm32
* Shell out to Node's `execSync` to execute `wasm2wat` over our wasm file
* Parse the wasm file line-by-line, looking for various function markers and
such
* Use the `elem` section to build a function pointer table, allowing us to map
exactly from function pointer to a function
* Avoid losing debug info (the names section) in release mode by stripping
`--strip-debug` from `rust-lld`.
* remove exclude list from Cargo.toml
* fix assert_instr for non-wasm targets
* re-format assert-instr changes
* add crate that uses assert_instr
* Fix instructions having extra quotes
* Add assert_instr for wasm memory intrinsics
* Remove hacks for git wasm-bindgen
* add wasm_simd128 feature
* make wasm32 build correctly
* run simd128 tests on ci
* remove wasm-assert-instr-tests
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.
* [core/runtime] use getauxval on non-x86 platforms
* test coresimd::auxv against auxv crate
* add test files from auxv crate
* [arm] use simd_test macro
* formatting
* missing docs
* improve docs
* reading /proc/self/auxv succeeds only if reading all fields succeeds
* remove cc-crate build dependency
* getauxval succeeds only if hwcap/hwcap2 are non-zero
* fix formatting
* move getauxval to stdsimd
* delete getauxval-wrapper.c
* remove auxv crate dev-dependency from coresimd
This commit adds a new crate for testing that the intrinsics listed in this
crate do indeed match the upstream definition of each intrinsic. A
pre-downloaded XML description of all Intel intrinsics is checked in which is
then parsed in the `stdsimd-verify` crate to verify that everything we write
down is matched against the upstream definitions.
Currently the checks are pretty loose to get this compiling but a few intrinsics
were fixed as a result of this. For example:
* `_mm256_extract_epi8` - AVX2 intrinsic erroneously listed under AVX
* `_mm256_extract_epi16` - AVX2 intrinsic erroneously listed under AVX
* `_mm256_extract_epi32` - AVX2 intrinsic erroneously listed under AVX
* `_mm256_extract_epi64` - AVX2 intrinsic erroneously listed under AVX
* `_mm_tzcnt_32` - erroneously had `u32` in the name
* `_mm_tzcnt_64` - erroneously had `u64` in the name
* `_mm_cvtsi64_si128` - erroneously available on 32-bit platforms
* `_mm_cvtsi64x_si128` - erroneously available on 32-bit platforms
* `_mm_cvtsi128_si64` - erroneously available on 32-bit platforms
* `_mm_cvtsi128_si64x` - erroneously available on 32-bit platforms
* `_mm_extract_epi64` - erroneously available on 32-bit platforms
* `_mm_insert_epi64` - erroneously available on 32-bit platforms
* `_mm256_extract_epi16` - erroneously returned i32 instead of i16
* `_mm256_extract_epi8` - erroneously returned i32 instead of i8
* `_mm_shuffle_ps` - the mask argument was erroneously i32 instead of u32
* `_popcnt32` - the signededness of the argument and return were flipped
* `_popcnt64` - the signededness of the argument was flipped and the argument
was too large bit-wise
* `_mm_tzcnt_32` - the return value's sign was flipped
* `_mm_tzcnt_64` - the return value's sign was flipped
* A good number of intrinsics used `imm8: i8` or `imm8: u8` instead of `imm8:
i32` which Intel was using. (we were also internally inconsistent)
* A number of intrinsics working with `__m64` were instead working with i64/u64,
so they're now corrected to operate with the vector types instead.
Currently the verifications performed are:
* Each name in Rust is defined in the XML document
* The arguments/return values all agree.
* The CPUID features listed in the XML document are all enabled in Rust as well.
The type matching right now is pretty loose and has a lot of questionable
changes. Future commits will touch these up to be more strict and require closer
adherence with Intel's own types. Otherwise types like `i32x8` (or any integers
with 256 bits) all match up to `__m256i` right now, althoguh this may want to
change in the future.
Finally we're also not testing the instruction listed in the XML right now.
There's a huge number of discrepancies between the instruction listed in the XML
and the instruction listed in `assert_instr`, and those'll need to be taken care
of in a future commit.
Closes#240
* Enable a Cargo workspace for the repo
* Disable tests for proc-macro crates
* Move back to mounting source directory read-only
* Refactor test invocation to only test one crate with `--all`
This commit alters the test suite to unconditionally compile and run all tests,
regardless of the ambient target features enabled. This then uses a new
convenience macro, `#[simd_test]`, to guard all tests with the appropriate
`cfg_feature_enabled!` and also enable the `#[target_feature]` appropriately.
This commit adds a procedural macro which can be used to test instruction
generation in a lightweight way. The intention is that all functions are
annotated with:
#[cfg_attr(test, assert_instr(maxps))]
fn foo(...) {
// ...
}
and then during `cargo test --release` it'll assert the function `foo` does
indeed generate the instruction `maxps`. This only activates tests in optimized
mode to avoid debug mode inefficiencies, and it uses a literal invocation of
`objdump` and some parsing to figure out what instructions are inside each
function. Finally it also uses the `backtrace` crate to figure out the symbol
name of the relevant function and hook that up to the output of `objdump`.
I added a few assertions in the `sse` module to get some feedback, but curious
what y'all think of this!
