rust/library/stdarch/ci/run.sh

#!/bin/sh

set -ex

# Tests are all super fast anyway, and they fault often enough on travis that
# having only one thread increases debuggability to be worth it.
export RUST_TEST_THREADS=1
#export RUST_BACKTRACE=1
#export RUST_TEST_NOCAPTURE=1

# FIXME(rust-lang-nursery/stdsimd#120) run-time feature detection for ARM Neon
case ${TARGET} in
    aarch*)
        export RUSTFLAGS="${RUSTFLAGS} -C target-feature=+neon"
        ;;
    *)
        ;;
esac

FEATURES="strict,$FEATURES"

echo "RUSTFLAGS=${RUSTFLAGS}"
echo "FEATURES=${FEATURES}"
echo "OBJDUMP=${OBJDUMP}"

cargo_test() {
    cmd="cargo test --target=$TARGET --features $FEATURES $1"
    cmd="$cmd -p coresimd -p stdsimd --manifest-path crates/stdsimd/Cargo.toml"
    cmd="$cmd -- $2"
    $cmd
}

cargo_test
cargo_test "--release"
Add CI for more platforms This commit adds CI for a few more targets: * i686-unknown-linux-gnu * arm-unknown-linux-gnueabihf * armv7-unknown-linux-gnueabihf * aarch64-unknown-linux-gnu The CI here is structured around using a Docker container to set up a test environment and then QEMU is used to actually execute code from these platforms. QEMU's emulation actually makes it so we can continue to just use `cargo test`, as processes can be spawned from QEMU like `objdump` and files can be read (for libbacktrace). Ends up being a relatively seamless experience! Note that a number of intrinsics were disabled on i686 because they were failing tests, and otherwise a few ARM touch-ups were made to get tests passing. 2017-09-21 08:42:52 -07:00			`#!/bin/sh`

			`set -ex`

Fix i586 tests 2017-10-11 17:33:41 -07:00			`# Tests are all super fast anyway, and they fault often enough on travis that`
			`# having only one thread increases debuggability to be worth it.`
			`export RUST_TEST_THREADS=1`
adds AArch64's {s,u,f}{min,max}{v,p} and ARM's {vmov}{n,l} (#345) * adds {s,u,f}{min,max}{v,p} AArch64 intrinsics * adds {vmov}{n,l} ARM intrinsics Closes #314 . 2018-03-07 16:31:14 +01:00			`#export RUST_BACKTRACE=1`
			`#export RUST_TEST_NOCAPTURE=1`
Fix i586 tests 2017-10-11 17:33:41 -07:00
[neon] reciprocal square-root estimate (#121) 2017-10-18 20:16:34 +02:00			`# FIXME(rust-lang-nursery/stdsimd#120) run-time feature detection for ARM Neon`
			`case ${TARGET} in`
			`aarch*)`
			`export RUSTFLAGS="${RUSTFLAGS} -C target-feature=+neon"`
			`;;`
			`*)`
			`;;`
			`esac`

[ci] add intel_sde feature 2017-11-09 18:24:40 +01:00			`FEATURES="strict,$FEATURES"`

[neon] reciprocal square-root estimate (#121) 2017-10-18 20:16:34 +02:00			`echo "RUSTFLAGS=${RUSTFLAGS}"`
[ci] add intel_sde feature 2017-11-09 18:24:40 +01:00			`echo "FEATURES=${FEATURES}"`
[arm] runtime-detection support 2017-10-26 22:00:03 +02:00			`echo "OBJDUMP=${OBJDUMP}"`
[neon] reciprocal square-root estimate (#121) 2017-10-18 20:16:34 +02:00
Use workspaces and fix tests * 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` 2017-11-20 14:34:44 -08:00			`cargo_test() {`
Verify Intel intrinsics against upstream definitions (#251) 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 2017-12-29 11:52:27 -06:00			`cmd="cargo test --target=$TARGET --features $FEATURES $1"`
Reorganize and refactor source tree (#324) 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. 2018-02-18 10:07:35 +09:00			`cmd="$cmd -p coresimd -p stdsimd --manifest-path crates/stdsimd/Cargo.toml"`
Verify Intel intrinsics against upstream definitions (#251) 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 2017-12-29 11:52:27 -06:00			`cmd="$cmd -- $2"`
Use workspaces and fix tests * 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` 2017-11-20 14:34:44 -08:00			`$cmd`
			`}`

			`cargo_test`
			`cargo_test "--release"`