You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does anyone know a way to implement a fallback so that we can use intrinsics and fall back to the generic version if that fails? Otherwise we might add a feature to force the generic version on wasm for such browsers and the user will either have to supply a browser check to select the best version or live with the suboptimal performance on browsers supporting SIMD.
@llogiq A Wasm binary that includes unsupported intrinsics can fail to parse, even if it won't use them. This comment is accurate unfortunately BurntSushi/memchr#144 (comment):
The current way of doing feature detection with WASM on browsers is to try to load a small WASM with the specific feature and see whether it fails. See for example this library from Google.
The route memchr took BurntSushi/memchr#149 is to only use intrinsics when #[cfg(target_feature = "simd128")]. This way you can force the intrinsic or generic version at compile-time with or without RUSTFLAGS=-Ctarget-feature=+simd128. Alternately:
Apps can then build multiple binaries, and use feature detection to serve the optimal one. For the foreseeable future this is the only portable option as far as I know.
I believe I'm seeing the same as this issue with this crate:
Here's wasm2wat showing the functions at issue:
The text was updated successfully, but these errors were encountered: