Confusion between `target_feature` and runtime feature detection

[calebzulawski]

I'm working on a crate that uses SIMD intrinsics for various architectures and ran into 2 seemingly contradictory issues with the wasm32 and arm targets.

If I build for wasm32 without the simd128 feature, I still have access to the SIMD types. When I test I get errors such as:

wasm-ld: error: function signature mismatch: _ZN17generic_simd_test21assign_scalar_op_impl17ha42fab674cd3bd98E
>>> defined as (v128) -> void in /target/wasm32-unknown-emscripten/debug/deps/generic_simd_test-5e53622f2d526041.1odaqe15wmy6tg3n.rcgu.o
>>> defined as (i32, i32, i32, i32) -> void in /target/wasm32-unknown-emscripten/debug/deps/generic_simd_test-5e53622f2d526041.2ha4zx2tw8sj5cyc.rcgu.o

I'm not too familiar with wasm but it looks to me like a valid ABI issue. Maybe v128 and the associated intrinsics should be behind #[cfg(target_feature = "simd128")]?

Conversely, I have discovered that the NEON types/intrinsics are only available when built with the v7 and neon features, which is surprising to me since it looks like runtime feature detection should be possible on targets such as armv7-unknown-linux-gnueabihf. Even more confusing, I am not able to simply add -Ctarget-feature=+v7,+neon, maybe this is because core is already compiled?

I'm aware both wasm32 and arm are unstable and it's possible some of this behavior might be expected. Possible improvements I think could be helpful:

• Document that the simd128 feature is required and why
• Document that the v7 and neon features are required and why (and why runtime detection isn't possible?)

Thanks for any help!

[Amanieu]

cc @alexcrichton for the wasm stuff.

Regarding neon I am not exactly sure why the static features are required. It might be some historical reason that no longer applies, in which can you can attempt to fix it with a PR to see if the tests uncover any issue.

[alexcrichton]

Can you gist the code you're using for wasm? It definitely looks like a compiler bug we should fix!