alexcrichton opened issue #2943:
Given this wasm:
(module (memory 1) (func (export "_start") call 1 drop) (func (result v128) v128.const i32x4 0 0 0 0 i32.const 1 v128.load v128.xor) )when run this yields:
$ cargo run -- --enable-simd foo.wat Finished dev [unoptimized + debuginfo] target(s) in 0.20s Running `target/debug/wasmtime --enable-simd foo.wat` Error: failed to run main module `foo.wat` Caused by: 0: failed to invoke command default 1: wasm trap: out of bounds memory access wasm backtrace: 0: 0x4b - <unknown>!<wasm function 1> 1: 0x2d - <unknown>!<wasm function 0>It looks like in the disassembly
pxoris being used with a memory operand, but presumably that memory operand needs to be aligned and the instruction is trapping otherwise?cc @abrown, @jlb6740
alexcrichton labeled issue #2943:
Given this wasm:
(module (memory 1) (func (export "_start") call 1 drop) (func (result v128) v128.const i32x4 0 0 0 0 i32.const 1 v128.load v128.xor) )when run this yields:
$ cargo run -- --enable-simd foo.wat Finished dev [unoptimized + debuginfo] target(s) in 0.20s Running `target/debug/wasmtime --enable-simd foo.wat` Error: failed to run main module `foo.wat` Caused by: 0: failed to invoke command default 1: wasm trap: out of bounds memory access wasm backtrace: 0: 0x4b - <unknown>!<wasm function 1> 1: 0x2d - <unknown>!<wasm function 0>It looks like in the disassembly
pxoris being used with a memory operand, but presumably that memory operand needs to be aligned and the instruction is trapping otherwise?cc @abrown, @jlb6740
alexcrichton labeled issue #2943:
Given this wasm:
(module (memory 1) (func (export "_start") call 1 drop) (func (result v128) v128.const i32x4 0 0 0 0 i32.const 1 v128.load v128.xor) )when run this yields:
$ cargo run -- --enable-simd foo.wat Finished dev [unoptimized + debuginfo] target(s) in 0.20s Running `target/debug/wasmtime --enable-simd foo.wat` Error: failed to run main module `foo.wat` Caused by: 0: failed to invoke command default 1: wasm trap: out of bounds memory access wasm backtrace: 0: 0x4b - <unknown>!<wasm function 1> 1: 0x2d - <unknown>!<wasm function 0>It looks like in the disassembly
pxoris being used with a memory operand, but presumably that memory operand needs to be aligned and the instruction is trapping otherwise?cc @abrown, @jlb6740
abrown assigned issue #2943 (assigned to abrown):
Given this wasm:
(module (memory 1) (func (export "_start") call 1 drop) (func (result v128) v128.const i32x4 0 0 0 0 i32.const 1 v128.load v128.xor) )when run this yields:
$ cargo run -- --enable-simd foo.wat Finished dev [unoptimized + debuginfo] target(s) in 0.20s Running `target/debug/wasmtime --enable-simd foo.wat` Error: failed to run main module `foo.wat` Caused by: 0: failed to invoke command default 1: wasm trap: out of bounds memory access wasm backtrace: 0: 0x4b - <unknown>!<wasm function 1> 1: 0x2d - <unknown>!<wasm function 0>It looks like in the disassembly
pxoris being used with a memory operand, but presumably that memory operand needs to be aligned and the instruction is trapping otherwise?cc @abrown, @jlb6740
abrown commented on issue #2943:
presumably that memory operand needs to be aligned and the instruction is trapping otherwise
I can confirm this is the case. When I run
cargo run -p cranelift-tools -- wasm --set="enable_simd=true" --target x86_64 -dDv scratch.watwith the code above I see the following:Disassembly of 48 bytes: 0: 55 push rbp 1: 48 89 e5 mov rbp, rsp 4: f3 0f 6f 05 14 00 00 00 movdqu xmm0, xmmword ptr [rip + 0x14] c: 48 8b 37 mov rsi, qword ptr [rdi] f: 66 0f ef 46 01 pxor xmm0, xmmword ptr [rsi + 1] 14: 48 89 ec mov rsp, rbp 17: 5d pop rbp 18: c3 ret 19: 00 00 add byte ptr [rax], al ...There are two problems here:
- an optimization issue:
MOVDQU, the unaligned move for double-quadwords (128-bit), is used to materialize the constant at offset19(relative14) into an XMM register. This actually should just be lowered to aPXORand I'm not entirely sure why the x64 backend is not doing this- an alignment issue, causing the crash:
PXORis using load-coalescing for its second operand,xmmword ptr [rsi + 1], instead of aMOVDQU + PXORsequence. This points out that load-coalescing is being over-eager: we should only be load coalescing 128-bit values if we know the load offset is aligned, perhaps using Wasm'smemargalignment.
abrown closed issue #2943 (assigned to abrown):
Given this wasm:
(module (memory 1) (func (export "_start") call 1 drop) (func (result v128) v128.const i32x4 0 0 0 0 i32.const 1 v128.load v128.xor) )when run this yields:
$ cargo run -- --enable-simd foo.wat Finished dev [unoptimized + debuginfo] target(s) in 0.20s Running `target/debug/wasmtime --enable-simd foo.wat` Error: failed to run main module `foo.wat` Caused by: 0: failed to invoke command default 1: wasm trap: out of bounds memory access wasm backtrace: 0: 0x4b - <unknown>!<wasm function 1> 1: 0x2d - <unknown>!<wasm function 0>It looks like in the disassembly
pxoris being used with a memory operand, but presumably that memory operand needs to be aligned and the instruction is trapping otherwise?cc @abrown, @jlb6740
Last updated: Dec 13 2025 at 19:03 UTC