cfallin commented on Issue #2060:
@abrown, I haven't looked at the patch, but regarding the regalloc error: this happens when a register is used before any defs in the vcode, so it's upward-exposed to the entry. Probably one of the lowerings is missing a move, or has the wrong destination?
cfallin commented on Issue #2060:
... and on review, this is probably coming from your
RawBitcast
lowering: if an op does nothing, it still needs to emit a move, because each SSA value (i.e. the input and output of the bitcast op) is allocated a new vreg; so the output needs a def somewhere.
cfallin edited a comment on Issue #2060:
... and on review, this is probably coming from your
RawBitcast
lowering: if an op does nothing, it still needs to emit a move, because each SSA value (i.e. the input and output of the bitcast op) is allocated a new vreg; so the output needs a def somewhere. (These moves are often/usually elided before emission by the regalloc if it can coalesce the vregs.)
github-actions[bot] commented on Issue #2060:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:x64"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
abrown commented on Issue #2060:
This should be ready for review; obviously some of this will have to be refined as more instructions are added (I added TODOs as appropriate).
abrown commented on Issue #2060:
@bnjbvr, I've made changes from the comments above but there are two larger issues to be resolved (and some renaming and refactoring comments left unresolved above):
- The get/map_regs could should be refactored and will be in #2071; I propose that we merge this first so that #2071 can then include both the XOR case (existing) and the CMPP* case (from this PR).
- The other issue is this:
$ cargo run --color=always --features experimental_x64 -- wast --enable-simd tests/spec_testsuite/proposals/simd/simd_f64x2_arith.wast Finished dev [unoptimized + debuginfo] target(s) in 0.07s Running `target/debug/wasmtime wast --enable-simd tests/spec_testsuite/proposals/simd/simd_f64x2_arith.wast` Error: failed to run script file 'tests/spec_testsuite/proposals/simd/simd_f64x2_arith.wast' Caused by: 0: failed directive on tests/spec_testsuite/proposals/simd/simd_f64x2_arith.wast:5189:1 1: wasm trap: call stack exhausted wasm backtrace: 0: 0x9a - <unknown>!<wasm function 4>
I've tried debugging with GDB but I just end up with a few waiting threads after a
SIGUSR1
signal--no hint of the compiled code. I've looked intorr
but I don't exactly see how this helps; perhaps we can discuss more?
abrown commented on Issue #2060:
@bnjbvr, I resolved the failures I was seeing (a combination of incorrect shift emission and missing a lowering for
vconst
). For future reference, I was able to side-step the weird signal error by running the binary directly:target/debug/wasmtime wast --enable-simd -g tests/spec_testsuite/proposals/simd/simd_f32x4_arith.wast
. With some fixes and the addition of some initial 128-bit constant support in 3402400 (thanks @cfallin!), thesimd_f32x4_arith.wast
andsimd_f64x2_arith.wast
spec tests now pass:$ cargo run --features experimental_x64 -- wast --enable-simd tests/spec_testsuite/proposals/simd/simd_f64x2_arith.wast Finished dev [unoptimized + debuginfo] target(s) in 0.07s Running `target/debug/wasmtime wast --enable-simd tests/spec_testsuite/proposals/simd/simd_f64x2_arith.wast` $ cargo run --features experimental_x64 -- wast --enable-simd tests/spec_testsuite/proposals/simd/simd_f32x4_arith.wast Finished dev [unoptimized + debuginfo] target(s) in 0.07s Running `target/debug/wasmtime wast --enable-simd tests/spec_testsuite/proposals/simd/simd_f32x4_arith.wast`
Last updated: Nov 22 2024 at 16:03 UTC