Stream: git-wasmtime

Topic: wasmtime / issue #3217 Cranelift: unsolvable input to reg...

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2021 at 02:40):

ZekeMedley labeled issue #3217:

For the below .clif code Cranelift appears to pass unsolvable input to regalloc. This was previously investigated as an issue with regalloc, but after some investigation @cfallin suggested moving it here.

This has been observed to cause failures when using regalloc and the upcoming regalloc2.

.clif Test Case

function u0:0() -> r64 system_v {
    sig0 = (i64) -> r64 system_v
    sig1 = (r64, r64, r64) -> r64 system_v
    sig2 = (i64) -> r64 system_v
    sig3 = (i64) -> r64 system_v
    sig4 = (r64, r64, r64) -> r64 system_v
    sig5 = (r64, r64, r64) -> r64 system_v
    fn0 = colocated u0:2 sig0
    fn1 = colocated u0:5 sig1
    fn2 = colocated u0:2 sig2
    fn3 = colocated u0:2 sig3

block0:
    v0 = iconst.i64 8
    v1 = call fn0(v0)
    v2 = func_addr.r64 fn1
    store v2, v1
    v3 = raw_bitcast.i64 v1
    v4 = bor_imm v3, 6
    v5 = raw_bitcast.r64 v4
    v6 = raw_bitcast.i64 v5
    v7 = band_imm v6, -8
    v8 = raw_bitcast.r64 v7
    v9 = load.r64 v8
    v10 = iconst.i64 1
    v11 = raw_bitcast.r64 v10
    v12 = iconst.i64 8
    v13 = call fn2(v12)
    v14 = raw_bitcast.i64 v5
    v15 = band_imm v14, -8
    v16 = raw_bitcast.r64 v15
    v17 = load.r64 v16
    v18 = iconst.i64 1
    v19 = raw_bitcast.r64 v18
    v20 = iconst.i64 8
    v21 = call fn3(v20)
    v22 = iconst.i64 8
    v23 = raw_bitcast.r64 v22
    store v23, v21
    v24 = call_indirect sig4, v17(v16, v19, v21)
    store v24, v13
    v25 = call_indirect sig5, v9(v8, v11, v13)
    return v25
}

Steps to Reproduce

  1. Place .clif test case above in a file fn.clif
  2. Run cargo run -p cranelift-tools -- compile --target x86_64 -D fn.clif and observe a panic.
thread 'main' panicked at 'assertion failed: vlr_env[cand_vlrix].is_ref == is_ref', /Users/zekemedley/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc-0.0.31/src/bt_spillslot_allocator.rs:298:13

Reproduction with regalloc2

  1. Place .clif test case above in a file fn.clif
  2. Follow the insutructions here for compiling Cranelift with regalloc2.
  3. Run cargo run -p cranelift-tools -- compile --target x86_64 -D fn.clif and observe a panic.
thread 'main' panicked at 'Minimal bundle with conflict!', /Users/zekemedley/Desktop/projects/lust/regalloc-bug/regalloc2/src/ion/process.rs:763:13

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2021 at 02:40):

ZekeMedley opened issue #3217:

For the below .clif code Cranelift appears to pass unsolvable input to regalloc. This was previously investigated as an issue with regalloc, but after some investigation @cfallin suggested moving it here.

This has been observed to cause failures when using regalloc and the upcoming regalloc2.

.clif Test Case

function u0:0() -> r64 system_v {
    sig0 = (i64) -> r64 system_v
    sig1 = (r64, r64, r64) -> r64 system_v
    sig2 = (i64) -> r64 system_v
    sig3 = (i64) -> r64 system_v
    sig4 = (r64, r64, r64) -> r64 system_v
    sig5 = (r64, r64, r64) -> r64 system_v
    fn0 = colocated u0:2 sig0
    fn1 = colocated u0:5 sig1
    fn2 = colocated u0:2 sig2
    fn3 = colocated u0:2 sig3

block0:
    v0 = iconst.i64 8
    v1 = call fn0(v0)
    v2 = func_addr.r64 fn1
    store v2, v1
    v3 = raw_bitcast.i64 v1
    v4 = bor_imm v3, 6
    v5 = raw_bitcast.r64 v4
    v6 = raw_bitcast.i64 v5
    v7 = band_imm v6, -8
    v8 = raw_bitcast.r64 v7
    v9 = load.r64 v8
    v10 = iconst.i64 1
    v11 = raw_bitcast.r64 v10
    v12 = iconst.i64 8
    v13 = call fn2(v12)
    v14 = raw_bitcast.i64 v5
    v15 = band_imm v14, -8
    v16 = raw_bitcast.r64 v15
    v17 = load.r64 v16
    v18 = iconst.i64 1
    v19 = raw_bitcast.r64 v18
    v20 = iconst.i64 8
    v21 = call fn3(v20)
    v22 = iconst.i64 8
    v23 = raw_bitcast.r64 v22
    store v23, v21
    v24 = call_indirect sig4, v17(v16, v19, v21)
    store v24, v13
    v25 = call_indirect sig5, v9(v8, v11, v13)
    return v25
}

Steps to Reproduce

  1. Place .clif test case above in a file fn.clif
  2. Run cargo run -p cranelift-tools -- compile --target x86_64 -D fn.clif and observe a panic.
thread 'main' panicked at 'assertion failed: vlr_env[cand_vlrix].is_ref == is_ref', /Users/zekemedley/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc-0.0.31/src/bt_spillslot_allocator.rs:298:13

Reproduction with regalloc2

  1. Place .clif test case above in a file fn.clif
  2. Follow the insutructions here for compiling Cranelift with regalloc2.
  3. Run cargo run -p cranelift-tools -- compile --target x86_64 -D fn.clif and observe a panic.
thread 'main' panicked at 'Minimal bundle with conflict!', /Users/zekemedley/Desktop/projects/lust/regalloc-bug/regalloc2/src/ion/process.rs:763:13

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2021 at 02:40):

ZekeMedley labeled issue #3217:

For the below .clif code Cranelift appears to pass unsolvable input to regalloc. This was previously investigated as an issue with regalloc, but after some investigation @cfallin suggested moving it here.

This has been observed to cause failures when using regalloc and the upcoming regalloc2.

.clif Test Case

function u0:0() -> r64 system_v {
    sig0 = (i64) -> r64 system_v
    sig1 = (r64, r64, r64) -> r64 system_v
    sig2 = (i64) -> r64 system_v
    sig3 = (i64) -> r64 system_v
    sig4 = (r64, r64, r64) -> r64 system_v
    sig5 = (r64, r64, r64) -> r64 system_v
    fn0 = colocated u0:2 sig0
    fn1 = colocated u0:5 sig1
    fn2 = colocated u0:2 sig2
    fn3 = colocated u0:2 sig3

block0:
    v0 = iconst.i64 8
    v1 = call fn0(v0)
    v2 = func_addr.r64 fn1
    store v2, v1
    v3 = raw_bitcast.i64 v1
    v4 = bor_imm v3, 6
    v5 = raw_bitcast.r64 v4
    v6 = raw_bitcast.i64 v5
    v7 = band_imm v6, -8
    v8 = raw_bitcast.r64 v7
    v9 = load.r64 v8
    v10 = iconst.i64 1
    v11 = raw_bitcast.r64 v10
    v12 = iconst.i64 8
    v13 = call fn2(v12)
    v14 = raw_bitcast.i64 v5
    v15 = band_imm v14, -8
    v16 = raw_bitcast.r64 v15
    v17 = load.r64 v16
    v18 = iconst.i64 1
    v19 = raw_bitcast.r64 v18
    v20 = iconst.i64 8
    v21 = call fn3(v20)
    v22 = iconst.i64 8
    v23 = raw_bitcast.r64 v22
    store v23, v21
    v24 = call_indirect sig4, v17(v16, v19, v21)
    store v24, v13
    v25 = call_indirect sig5, v9(v8, v11, v13)
    return v25
}

Steps to Reproduce

  1. Place .clif test case above in a file fn.clif
  2. Run cargo run -p cranelift-tools -- compile --target x86_64 -D fn.clif and observe a panic.
thread 'main' panicked at 'assertion failed: vlr_env[cand_vlrix].is_ref == is_ref', /Users/zekemedley/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc-0.0.31/src/bt_spillslot_allocator.rs:298:13

Reproduction with regalloc2

  1. Place .clif test case above in a file fn.clif
  2. Follow the insutructions here for compiling Cranelift with regalloc2.
  3. Run cargo run -p cranelift-tools -- compile --target x86_64 -D fn.clif and observe a panic.
thread 'main' panicked at 'Minimal bundle with conflict!', /Users/zekemedley/Desktop/projects/lust/regalloc-bug/regalloc2/src/ion/process.rs:763:13

view this post on Zulip Wasmtime GitHub notifications bot (Aug 20 2021 at 02:47):

cfallin commented on issue #3217:

To add some detail here: this is related to reftypes support. What appears to be happening is that Cranelift is generating VCode with register constraints that somehow require a reftyped value to be both on the stack and in a register at the same time.

I suspect it has to do with the bitcast that moves a value between reftyped and non-reftyped domains. We don't see this issue with WebAssembly's reference types because one cannot actually move a reference out of that domain -- it can never become an integer, it can only be used as an argument or return value leaving the Wasm domain. My understanding is that @ZekeMedley is building a compiler that emits CLIF and is actually using the reference-type support to handle pointers, and dereference them, in a system that requires precise GC rooting.

This may indicate that we'll have similar issues in the future when we implement Wasm-GC, so it's worth finding the issue now -- thanks for filing the issue here!

Last updated: Oct 23 2024 at 20:03 UTC