It turns out that providing routines with #[target_feature(enable = "simd128")] on wasm32 can fail in some older browsers. The specific
problem is not totally clear to me, but it is straight-forward enough
to fix (I hope) by just requiring that simd128 be enabled at compile
time in order to include the wasm32 SIMD modules in this crate.
This would not be a great solution if WASM supported runtime CPU
feature detection. And the status quo is that simd128 has to be
enabled at compile time anyway for the SIMD code to take effect. So
this shouldn't cause any regressions and is likely something we can do
long term as well. We can re-evaluate once and if WASM gets support for
runtime CPU feature detection.
We also add a CI test for wasm32without the simd128 target
feature enabled.
It turns out that providing routines with
#[target_feature(enable = "simd128")]
onwasm32
can fail in some older browsers. The specific problem is not totally clear to me, but it is straight-forward enough to fix (I hope) by just requiring thatsimd128
be enabled at compile time in order to include thewasm32
SIMD modules in this crate.This would not be a great solution if WASM supported runtime CPU feature detection. And the status quo is that
simd128
has to be enabled at compile time anyway for the SIMD code to take effect. So this shouldn't cause any regressions and is likely something we can do long term as well. We can re-evaluate once and if WASM gets support for runtime CPU feature detection.We also add a CI test for
wasm32
without thesimd128
target feature enabled.Fixes #144