alexcrichton opened Issue #2666:
I was doing a bit of work today to sync rust-lang/rust's wasm simd support with the current spec, but unfortunately the file produced by LLVM couldn't execute in wasmtime due to a panic:
thread '<unnamed>' panicked at 'ABI argument v5 should be in a register', cranelift/codegen/src/regalloc/coloring.rs:409:21
This can be reproduced with this wasm file by running:
$ wasmtime core_arch-0fbe1ece0f9fbcb5.wasm --enable-simd thread '<unnamed>' panicked at 'ABI argument v5 should be in a register', /Users/acrichton/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.70.0/src/regalloc/coloring.rs:409:21 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' panicked at 'ABI argument v4 should be in a register', /Users/acrichton/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.70.0/src/regalloc/coloring.rs:409:21 thread '<unnamed>' panicked at 'ABI argument v5 should be in a register', /Users/acrichton/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.70.0/src/regalloc/coloring.rs:409:21
Note that I'm testing the main branch of the repo as-of-now which means the fix for https://github.com/bytecodealliance/wasmtime/pull/2658 didn't cover this case as well.
abrown commented on Issue #2666:
On x64?
alexcrichton commented on Issue #2666:
It looks like this doesn't happen on x64, only on the old backend. Do we not care enough about the old backend to fix it?
It also looks like there's unsupported opcodes in that file as well so it won't finish running anyway (the new backend stops at a wasm validation error for unknown opcodes)
cfallin commented on Issue #2666:
It seems to me that this tradeoff (fix vs. wait) depends on relative timings. The switch to the new backend as Wasmtime's default will hopefully happen soon; it depends on a little more implementation (Windows support) which I'm hoping to get to next week. However if this becomes a blocker to fully supporting SIMD then we could certainly dig into the old regalloc. There might be significant ramp-up time there, though. It seems to me that the more important question is whether the old regalloc continues to generate correct code when it doesn't panic (if not, we need to jump on it right away); otherwise on balance I'd say we should just wait for the transition. Thoughts?
alexcrichton commented on Issue #2666:
Oh this isn't urgent at all, I mostly wanted to just report the issue in case it wasn't already known. If it's known that x64 fixes this and x86 isn't expected to get fixed any time soon, then I think closing this is quite reasonable!
alexcrichton closed Issue #2666:
I was doing a bit of work today to sync rust-lang/rust's wasm simd support with the current spec, but unfortunately the file produced by LLVM couldn't execute in wasmtime due to a panic:
thread '<unnamed>' panicked at 'ABI argument v5 should be in a register', cranelift/codegen/src/regalloc/coloring.rs:409:21
This can be reproduced with this wasm file by running:
$ wasmtime core_arch-0fbe1ece0f9fbcb5.wasm --enable-simd thread '<unnamed>' panicked at 'ABI argument v5 should be in a register', /Users/acrichton/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.70.0/src/regalloc/coloring.rs:409:21 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' panicked at 'ABI argument v4 should be in a register', /Users/acrichton/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.70.0/src/regalloc/coloring.rs:409:21 thread '<unnamed>' panicked at 'ABI argument v5 should be in a register', /Users/acrichton/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.70.0/src/regalloc/coloring.rs:409:21
Note that I'm testing the main branch of the repo as-of-now which means the fix for https://github.com/bytecodealliance/wasmtime/pull/2658 didn't cover this case as well.
Last updated: Nov 22 2024 at 16:03 UTC