`hwy::DispatchedTarget` always returns HWY_EMU128 on WASM/Emscripten

[LanderlYoung]

The reason is the highway library isn't compiled with -msimd128.

My project is compiled with Emscripten with -msimd128 flag.
I'm using CMake and FetchContent to download source of highway, and FetchContent used add_subdirectory to integrate highway in to my build.
And the HWY_DYNAMIC_DISPATCH macro is doing great by selecting HWY_WASM target.

Current viable solution is using include instead of add_subdirectory in cmake, and add -msimd128 flag to highway manually.

Or, I'd like to discuss:

1. Is it possible for WASM to auto detect and enable WASM SIMD by pragma like avx targets? (without manually adding compiler flags).
2. Maybe landing Question: header only version ? #2114 is also a great idea. (I'd like to try that, but it may produce a big change list)

[jan-wassenberg]

Ah, makes sense. From a quick test on Godbolt Clang webassembly, adding __attribute__((target("simd128"))) seems to be accepted, whereas other strings do raise a warning.
You could try, in detect_targets.h, adding something like HWY_HAVE_RUNTIME_DISPATCH_APPLE for WASM, checking HWY_ARCH_WASM and HWY_COMPILER_CLANG (perhaps a recent version), then add that as another precondition for HWY_HAVE_RUNTIME_DISPATCH. This might then work out of the box. If it does, we'd welcome a PR (to the dev branch) :)

[LanderlYoung]

Thanks for the reply, I'll give it a try and maybe create a PR latter😜

[LanderlYoung]

Turns out highway has already defined the compiler attribute in set_macros-inl.h

#define HWY_NAMESPACE N_WASM

#define HWY_TARGET_STR "simd128"

The Reason

The reason is detect_targets.h also checks for __wasm_simd128__ (which relays on -msimd128 compiler flag)

#if HWY_ARCH_WASM && defined(__wasm_simd128__)

After remove the check, everthing works fine. And my project don't need to pass -msimd128 explicitly.

The Catch

For users who disable target by HWY_DISABLED_TARGETS, the problem still exist.

Some use may want to disable simd feature for some reason (like browser compatility), but the per_target.cc will still has a N_WASM implementation generated, luckly the generated code doesn't contain any simd instruction.

But it beyond the scope of the topic.

The Fix

Index: hwy/detect_targets.h

-#if HWY_ARCH_WASM && defined(__wasm_simd128__)
+#if HWY_ARCH_WASM

I'd like to open a PR if appropriate, thanks ❤️

[jan-wassenberg]

hm, I can see how the proposed change works, but I'm not sure that is the correct way to go.
The question is: do we ever want to have WASM without SIMD? Maybe. Until recently, -msimd128 didn't even work on our test machines.
I think it would be better to compile two codepaths, one with and one without SIMD, using the dynamic dispatch. Would you also like to try the HWY_HAVE_RUNTIME_DISPATCH change proposed above that would enable that?

[LanderlYoung]

If I understand you correctly, you're suggesting compiling with two targets (like HWY_SCALAR and HWY_WASM) and selecting them with dynamic dispatch by checking if the browser supports the wasm128 feature at runtime.
I'm afraid this is not possible.

Unlike native code, WebAssembly verifies the binary at the very beginning when calling functions from the WebAssembly.instantiate family.
For example, if a browser supports WebAssembly but doesn't support the wasm128 feature, the entire WebAssembly binary will be rejected.

A common solution is to compile a fully featured WebAssembly binary alongside a fallback JavaScript file, and check browser compatibility before loading the WebAssembly binary.

• To test browser compatibility, one can use wasm-feature-detect.
• To compile a pure JavaScript fallback, the WASM option in Emscripten can be useful.

Another thing to note is that when compiling a pure JavaScript fallback, the compiler must not emit any wasm128 instruction; otherwise, the process of converting the WebAssembly binary to a JavaScript file will fail.

That is also why I need to disable the wasm128 feature when compiling the WebAssembly binary.

[johnplatts]

If I understand you correctly, you're suggesting compiling with two targets (like HWY_SCALAR and HWY_WASM) and selecting them with dynamic dispatch by checking if the browser supports the wasm128 feature. I'm afraid this is not possible.

Unlike native code, WebAssembly verifies the binary at the very beginning when calling functions from the WebAssembly.instantiate family. For example, if a browser supports WebAssembly but doesn't support the wasm128 feature, the entire WebAssembly binary will be rejected.

A common solution is to compile a fully featured WebAssembly binary alongside a fallback JavaScript file, and check browser compatibility before loading the WebAssembly binary.

• To test browser compatibility, one can use wasm-feature-detect.
• To compile a pure JavaScript fallback, the WASM option in Emscripten can be useful.

Another thing to note is that when compiling a pure JavaScript fallback, the compiler must not emit any wasm128 instruction; otherwise, the process of converting the WebAssembly binary to a JavaScript file will fail.

That is also why I need to disable the wasm128 feature when compiling the WebAssembly binary.

I agree that the best approach to building both the EMU128 and WASM targets for WebAssembly is to compile separate binaries for the HWY_EMU128 and HWY_WASM targets, and using wasm-feature-detect to detect support for the HWY_WASM target (instead of the Google Highway dynamic dispatch mechanism that is designed for targets that compile to native code).

[jan-wassenberg]

Got it, thanks. I will add a comment to HWY_HAVE_RUNTIME_DISPATCH saying "Wasm does not [support runtime dispatch], because browsers reject a binary containing any SIMD instructions when the browser does not support them."

If we have two separate binaries (one built with -m flag), are any changes required?

[LanderlYoung]

If we have two separate binaries (one built with -m flag), are any changes required?

We have two approaches:

1. Developers must pass the -msimd128 flag manually.

I've tested 3 scenarios:

1. Compiling with -msimd128 flag

# cmake config
target_compile_options(test_target PRIVATE -msimd128)

The HWY_WASM target is statically detected & enabled.

2. Compiling with -msimd128 flag and HWY_DISABLED_TARGETS macro to disable HWY_WASM

target_compile_options(test_target PRIVATE -msimd128)
target_compile_definitions(test_target PRIVATE HWY_DISABLED_TARGETS=HWY_WASM)

The HWY_EMU128 target is statically detected & enabled.

3. Compiling without -msimd128 flag
TheHWY_EMU128 target is statically detected & enabled.

As long as the requirement is documented, this is good enough.

2. We enable wasm simd implicitly

Like discussed before, by appling this change

Index: hwy/detect_targets.h

-#if HWY_ARCH_WASM && defined(__wasm_simd128__)
+#if HWY_ARCH_WASM

Highway enable HWY_WASM automatically, and developer can disable this target by HWY_DISABLED_TARGETS.

The behavior is consistent with that on other architectures and aligns with the documentation.

---

I personaly prefer the second approach.

[jan-wassenberg]

Makes sense, I'd be fine with an opt-out as you propose, now that WASM SIMD is more or less widespread.
Would you like to send a pull request? If so, please add a comment explaining why it's convenient to avoid -msimd128.

[LanderlYoung]

Makes sense, I'd be fine with an opt-out as you propose, now that WASM SIMD is more or less widespread. Would you like to send a pull request? If so, please add a comment explaining why it's convenient to avoid -msimd128.

sure 🚀