Start testing runtime execution of wasm32 simd intrinsics

[alexcrichton]

This commit starts to add support to CI to not only compile all wasm32 SIMD intrinsics but also actually execute some of them at runtime. The master branch of the nodejs/node repository has recently merged an update of v8 which aligns internal opcode definitions with the most recent version of the wasm SIMD spec. As a result we can start actually executing some WebAssembly code with SIMD instructions in it!

Unfortunately not all SIMD instructions are implemented in v8 right now. In LLVM this is known as the +simd128 feature (what v8 implements) and the +unsupported-simd128 (everything v8 doesn't implement but is spec'd). We continue to compile the library with both features (to make sure it works) but this PR then also adds a mdoe where it compiles with only +simd128 and executes the resulting binary in node.js. Unfortunately compiling with just +simd128 results in lots of LLVM errors, so we also compile with --cfg only_node_compatible to statically remove non-node-compatible functions.

The end result is that we're successfully executing all #[assert_instr] annotations! Additionally I've started uncommenting some tests in mod tests and updating them to the new intrinsic names. There's still a lot more work to be done there, but I figured it'd be good to post this for initial feedback.

In general, the changes here are:

• Compile a version of Node.js with wasm support (can download binaries once node 12 is released)
• Update CI to dynamically download the right version of wasm-bindgen instead of pinning
• Add #[cfg] to optionally remove SIMD which isn't implemented in node.js
• Add CI configuration to execute select SIMD tests in node.js

[alexcrichton]

I should also point out that building node on CI may just take too long, so we may want to just hold off on this until Node 12 is release. (I don't know when that will be, but I presume not too far in the future)

[gnzlbg]

Looks like the build job is getting very close to the 50min travis time limit (49min ..). The error is:

Removing intermediate container ec77fe5cf34f
Successfully built 97372c202902
Successfully tagged stdsimd:latest
+mkdir -p target
+echo Running docker
Running docker
+id -u
+id -g
+rustc --print sysroot
+pwd
+pwd
+docker run --user 2000:2000 --rm --init --volume /home/travis/.cargo:/cargo-h --env CARGO_HOME=/cargo-h --volume /home/travis/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu:/rust:ro --env TARGET=wasm32-unknown-unknown --env STDSIMD_TEST_EVERYTHING --env STDSIMD_ASSERT_INSTR_IGNORE --env STDSIMD_DISABLE_ASSERT_INSTR --env NOSTD --env NORUN --env RUSTFLAGS --env STDSIMD_TEST_NORUN --volume /home/travis/build/rust-lang-nursery/stdsimd:/checkout:ro --volume /home/travis/build/rust-lang-nursery/stdsimd/target:/checkout/target --workdir /checkout --privileged stdsimd bash -c PATH=/rust/bin:$PATH exec ci/run.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100     9    0     9    0     0     44      0 --:--:-- --:--:-- --:--:--    44

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
travis_time:end:1a5d3d37:start=1555012192491503409,finish=1555015069636286444,duration=2877144783035
�[0K�[31;1mThe command "if [ "${NO_DOCKER}" = "1" ]; then
    ci/run.sh $TARGET
else
    ci/run-docker.sh $TARGET
fi
" exited with 2.�[0m



Done. Your build exited with 1.

so it appears that node does indeed build in that timeframe, but tar failed.

[alexcrichton]

Alas! That was probably a bug around the wasm-bindgen release but the 50m build time is a deal breaker for sure.

It looks like Node 12 may be released by the end of the month though, so we can try again around then!

[gnzlbg]

If you want to merge this in the meantime, a quick "fix" would be to just compile node 12 from source on Linux, tar it, and upload the result somewhere (e.g. a github repo_, and pull that here.

[alexcrichton]

It's possible yeah but there's not necessarily a burning need to get this in, so I'm fine waiting