Runtime crash with Rust + lto + simd + Emscripten EH

[kleisauke]

Given this example Rust program:
src/main.rs:

use std::collections::HashMap;

fn print_map(map: &HashMap<&str, &str>) {
    for (key, value) in map {
        println!("{}: {}", key, value);
    }
}

fn main() {
   let mut map = HashMap::new();
   map.insert("Hello", "world!");
   print_map(&map);
}

Fails at runtime when building with RUSTFLAGS="-Ctarget-feature=+simd128 -Clto -Cembed-bitcode=yes":

$ curl https://sh.rustup.rs -sSf | sh -s -- -y --profile minimal --target wasm32-unknown-emscripten --default-toolchain nightly-2023-10-09 --component rust-src
$ source "$HOME/.cargo/env"
$ cargo new foo
$ cd foo
$ cat <<EOT > src/main.rs
use std::collections::HashMap;

fn print_map(map: &HashMap<&str, &str>) {
    for (key, value) in map {
        println!("{}: {}", key, value);
    }
}

fn main() {
   let mut map = HashMap::new();
   map.insert("Hello", "world!");
   print_map(&map);
}
EOT
$ RUSTFLAGS="-g -Ctarget-feature=+simd128 -Clto -Cembed-bitcode=yes" cargo build --release -Zbuild-std=panic_abort,std --target wasm32-unknown-emscripten
$ node target/wasm32-unknown-emscripten/release/foo.js
/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:114
      throw ex;
      ^

TypeError: type incompatibility when transforming from/to JS
    at foo.wasm.foo::main::h87ae4359dffc67a0 (wasm://wasm/foo.wasm-0055ddf2:wasm-function[35]:0x13a3)
    at foo.wasm.std::sys_common::backtrace::__rust_begin_short_backtrace::hbc269fb224856d88 (wasm://wasm/foo.wasm-0055ddf2:wasm-function[30]:0x65a)
    at invoke_vi (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:3775:29)
    at foo.wasm.main (wasm://wasm/foo.wasm-0055ddf2:wasm-function[50]:0x2ea9)
    at Module._main (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:3715:90)
    at callMain (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:3903:15)
    at doRun (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:3942:23)
    at run (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:3957:5)
    at runCaller (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:3882:19)
    at removeRunDependency (/home/kleisauke/foo/target/wasm32-unknown-emscripten/release/foo.js:409:7)

Node.js v20.5.1

While debugging this, I noticed that LLVM generates a invoke_iiV wrapper in WebAssemblyLowerEmscriptenEHSjLj.cpp, which would suggests that it attempts to transmit a V128 value to JavaScript, which isn't supported.
https://github.com/llvm/llvm-project/blob/32f719776552542691f14e786400fc222b7416f1/llvm/lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp#L122-L123

Version of emscripten/emsdk:

$ emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.47-git (a57ebdc55bae77a6b4f7dd05422b381ead72c3fd)
clang version 18.0.0 (https://github.com/llvm/llvm-project 18622fc2f4bcd58f9076301babdfbcca9c0a70d0)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/kleisauke/emsdk/upstream/bin

Context: kleisauke/wasm-vips#48.

(Feel free to transfer this issue if it doesn't belong here)

[kleisauke]

Reduced to:
https://gist.github.com/kleisauke/aae76cdf253fae71fefec95fe0de76a5

$ curl -LO https://gist.github.com/kleisauke/aae76cdf253fae71fefec95fe0de76a5/raw/68bb7b6b10d9db97cd33418d41c9e5aba0db095c/reduced.ll
$ emcc -g -O3 -msimd128 reduced.ll -o test.js
$ node test.js && echo 'success w/o -fexceptions'
success w/o -fexceptions
$ emcc -g -O3 -msimd128 -fexceptions reduced.ll -o test.js
$ node test.js
/home/kleisauke/test.js:114
      throw ex;
      ^

TypeError: type incompatibility when transforming from/to JS
    at test.wasm.__original_main (wasm://wasm/test.wasm-0008c8fe:wasm-function[11]:0x31e)
    at test.wasm.main (wasm://wasm/test.wasm-0008c8fe:wasm-function[12]:0x343)
    at Module._main (/home/kleisauke/test.js:996:90)
    at callMain (/home/kleisauke/test.js:1088:15)
    at doRun (/home/kleisauke/test.js:1127:23)
    at run (/home/kleisauke/test.js:1142:5)
    at runCaller (/home/kleisauke/test.js:1075:19)
    at removeRunDependency (/home/kleisauke/test.js:404:7)
    at receiveInstance (/home/kleisauke/test.js:587:5)
    at receiveInstantiationResult (/home/kleisauke/test.js:599:5)

Node.js v20.5.1
$ grep -B1 'invoke_viV' test.js
  /** @export */
  invoke_viV: invoke_viV,
--

function invoke_viV(index,a1,a2) {

[kleisauke]

... even simpler reproducer in C++:
test.cpp

#include <stdio.h>
#include <string.h>

#include <wasm_simd128.h>

static void __attribute__((noinline)) print128_num(v128_t var) {
    uint16_t val[8];
    memcpy(val, &var, sizeof(val));
    printf("%i %i %i %i %i %i %i %i\n", 
           val[0], val[1], val[2], val[3], 
           val[4], val[5], val[6], val[7]);
    throw 42;
}

int main() {
    try {
        v128_t i = wasm_i16x8_splat(1);
        print128_num(i);
    } catch (...) {
    }

    return 0;
}

$ em++ -g -O3 -msimd128 test.cpp -o test.js
$ node test.js
1 1 1 1 1 1 1 1
...
$ em++ -g -O3 -msimd128 -fexceptions test.cpp -o test.js
/home/kleisauke/test.js:114
      throw ex;
      ^

TypeError: type incompatibility when transforming from/to JS
    at test.wasm.__original_main (wasm://wasm/test.wasm-0011e2da:wasm-function[16]:0x412)
    at test.wasm.main (wasm://wasm/test.wasm-0011e2da:wasm-function[18]:0x4f9)
    at Module._main (/home/kleisauke/test.js:1071:90)
    at callMain (/home/kleisauke/test.js:1174:15)
    at doRun (/home/kleisauke/test.js:1213:23)
    at run (/home/kleisauke/test.js:1228:5)
    at runCaller (/home/kleisauke/test.js:1161:19)
    at removeRunDependency (/home/kleisauke/test.js:404:7)
    at receiveInstance (/home/kleisauke/test.js:587:5)
    at receiveInstantiationResult (/home/kleisauke/test.js:599:5)

Node.js v20.5.1
$ grep -B1 'invoke_vV' test.js
  /** @export */
  invoke_vV: invoke_vV,
--

function invoke_vV(index,a1) {

[kripken]

Sounds like the wasm backend's emscripten-exceptions code is sending out a v128, which is not possible, yeah. In theory the fix would probably be to split it into chunks. But otoh the future is wasm-exceptions, and I verified that

em++ -g -O3 -msimd128 -fwasm-exceptions test.cpp -o test.js

works ok. Perhaps you can use wasm-exceptions in your project?

[sbc100]

I wonder if this should be supported and translated into a JS bitint value? bigint can hold a v128 just like it can hold an i64 right?

[kleisauke]

Perhaps you can use wasm-exceptions in your project?

I'm considering transitioning to Wasm EH instructions at some point, but I think it might be premature at the moment, especially since the proposal hasn't been standardized yet. In addition, it's worth noting that Rust has some quirks related to this, see for example:
rust-lang/rust#112195
https://github.com/rust-lang/rust/blob/5b88d659f8c2428536589d4bd36b9099d53a6815/compiler/rustc_codegen_ssa/src/base.rs#L333-L338

I wonder if this should be supported and translated into a JS bitint value? bigint can hold a v128 just like it can hold an i64 right?

The user-facing v128_t type is a typedef to int32_t, so perhaps it could be lowered to an integer?
https://github.com/llvm/llvm-project/blob/9ce8103e87397578137daf893bfc410b3a7db1dc/clang/lib/Headers/wasm_simd128.h#L17

However, I'm not sure if this is possible.

[kripken]

Translating a v128 to a BigInt seems worth proposing. There would a question of how to interpret the bits, signed or unsigned., but I guess we already do signed for i32 so maybe signed is the natural extension.

[sbc100]

Translating a v128 to a BigInt seems worth proposing. There would a question of how to interpret the bits, signed or unsigned., but I guess we already do signed for i32 so maybe signed is the natural extension.

Yes, it seems like we already had to decide how to do that for i64 <-> BigInt too right?

[kleisauke]

I'll close this as "won't fix" for now. A v128 data type cannot be exposed to JS currently, issue WebAssembly/design#1502 is a future possible enhancement that relates to this.