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
pxor
is 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
pxor
is 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
pxor
is 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
pxor
is 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.wat
with 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 aPXOR
and I'm not entirely sure why the x64 backend is not doing this- an alignment issue, causing the crash:
PXOR
is using load-coalescing for its second operand,xmmword ptr [rsi + 1]
, instead of aMOVDQU + PXOR
sequence. 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'smemarg
alignment.
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
pxor
is 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: Nov 22 2024 at 17:03 UTC