wasm simd: folded xor and unaligned load incorrectly "traps"

[alexcrichton]

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]

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 offset 19 (relative 14) into an XMM register. This actually should just be lowered to a PXOR 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 a MOVDQU + 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's memarg alignment.