Wasm simd128 support

[myfreeer]

Based on the compact code by emscripten, most part of the x86 sse2 simd code can be rewritten into wasm simd128.
Initial work here, it should compile both library and tests with clang and wasi-sdk with cmake arguments below:

-DCMAKE_C_FLAGS="-msimd128 -D_WASI_EMULATED_PROCESS_CLOCKS"
-DCMAKE_EXE_LINKER_FLAGS="-lwasi-emulated-process-clocks"
-DCGLM_STATIC=ON
-DCMAKE_TOOLCHAIN_FILE=/path/to/wasi-sdk-19.0/share/cmake/wasi-sdk.cmake
-DWASI_SDK_PREFIX=/path/to/wasi-sdk-19.0
-DCGLM_USE_TEST=ON

Where /path/to/wasi-sdk-19.0/ is the path to extracted wasi sdk.

Here is an example of compiled tests:
compiled_tests_for_wasi.zip
This should run on wasmtime and wasmer runtime with simd128 support and pass the tests.

[recp]

Hi @myfreeer,

Wow that's great! Would you like to bring this via a PR?

[myfreeer]

There are still things to do, imcomplete listed below:

1. Inline or rewrite sse2 wrappers borrowed from emscripten
2. Change in cmake scripts for cmake arguments, or a build guide
3. Code style changes

So maybe a draft pr could be made first, and it would take some time to finish this.

[recp]

@myfreeer many thanks, I'll wait that PR :)

[recp]

@myfreeer is it possible to get additional wasm improvements and postponed tasks at #286 :) moving Compiling section (with or without more documentation) in the PR to README, build.rst could be nice too

[myfreeer]

It's here: #295

[recp]

@myfreeer many thanks

[kzhsw]

It seems that the current wasm compiler lacks compile-time contant evaluation feature, here is an example taken from simd/x86/quat.h and simd/wasm/quat.h:

Wasm:
shuffle + store

x86:
movaps + movups

Wasm link: https://godbolt.org/z/aoEer7cd9
x86 link: https://godbolt.org/z/aoEer7cd9

[myfreeer]

The link for x86 is the same as wasm, here is a reproduced x86 link with code above: https://godbolt.org/z/qoWeEEnan, maybe this should be reported to llvm-project instead.

[myfreeer]

It does not seem to reproduce on Debian clang version 14.0.6 and clang version 16.0.0 (wasi-sdk 20), I manually compiled this to wasm, but wasm2wat shows a different result.

source_and_compiled_binary_attached_here.zip

[gottfriedleibniz]

One potential alternative would be to experiment with wasm_i32x4_shuffle versus __builtin_shufflevector. The former is emitting @llvm.wasm.shuffle and there may be some baggage/boundary/something preventing its evaluation.

[kzhsw]

It seems that __builtin_shufflevector is more effecient in godbolt clang here https://godbolt.org/z/Yx5vY9ndc, futher tests might also be needed in local compilers like wasi clang.

[recp]

Maybe we can use __builtin_shufflevector instead of wasm_i32x4_shuffle when possible ( maybe some other SIMD instructions too ), because it seems wasm_i32x4_shuffle is not well-supported: https://emscripten.org/docs/porting/simd.html?highlight=exception, something like CGLM_WASM_ENABLE_EXPERIMENT could force to use wasm_i32x4_shuffle instead of __builtin_shufflevector ...?

[myfreeer]

Found a type here