Stream: git-wasmtime

Topic: wasmtime / issue #11183 Cranelift: unexpected panic on ri...

Wasmtime GitHub notifications bot (Jul 04 2025 at 13:35):

akldc opened issue #11183:

.clif Test Case

test optimize
set opt_level=none
set preserve_frame_pointers=true
set enable_multi_ret_implicit_sret=true
target x86_64 sse42 has_avx
target aarch64
target s390x
target riscv64gc  has_zcd has_zbkb has_zbc has_zbs has_zicond has_zvl32b has_zvl64b has_zvl128b has_zvl1024b has_zvl2048b has_zvl4096b has_zvl8192b has_zvl16384b has_zvl32768b

function u1:6(f32, f32) -> f32, f32  {
block0(v0: f32, v1: f32):
    return v0, v0
}


function u1:5(i64 , f32) ->  f32  {
    sig0 = (f32, f32) -> f32, f32
    fn0 = u1:6 sig0

block0(v0: i64, v1: f32):
    v17 = iconst.i64 0
    v23 = f32const 0x1.5270eep-1
    v24 = select_spectre_guard.f32 v0, v1, v23
    v26, v27 = call fn0(v23, v24)
    return  v23
}

function %main() -> f32  {
    sig0 = (i64 , f32) ->  f32
    fn0 = u1:5 sig0

block0:
    v3 = iconst.i64 23
    v4 = f32const 0x1.5270eep-1
    v5 = call fn0(v3,v4)
    return v5
}

; print: %main()

Result

[x86    ] %main() -> 0x1.5270eep-1
return code: 0

[riscv64] thread 'main' panicked at cranelift/codegen/src/isa/riscv64/lower/isle.rs:169:22:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
return code: 101

I tried removing the instruction v26, v27 = call fn0(v23, v24), and that made the case run successfully.
I'm not sure whether this issue is related to #10951

Wasmtime GitHub notifications bot (Jul 04 2025 at 13:35):

akldc added the bug label to Issue #11183.

Wasmtime GitHub notifications bot (Jul 04 2025 at 13:35):

akldc added the cranelift label to Issue #11183.

Wasmtime GitHub notifications bot (Jul 04 2025 at 14:11):

bjorn3 commented on issue #11183:

Can you run again with RUST_BACKTRACE=1 and post the backtrace?

Wasmtime GitHub notifications bot (Jul 04 2025 at 18:53):

primoly commented on issue #11183:

This is caused by the RISC-V lowering of select_spectre_guard calling rv_and and rv_andn with FReg (x and y),[^1] but they each expect two XReg.[^2][^3]

[^1]: https://github.com/bytecodealliance/wasmtime/blob/b63c25ae22c53b66904b6988071cfa72c051cfbf/cranelift/codegen/src/isa/riscv64/lower.isle#L2616
[^2]: https://github.com/bytecodealliance/wasmtime/blob/b63c25ae22c53b66904b6988071cfa72c051cfbf/cranelift/codegen/src/isa/riscv64/inst.isle#L1156
[^3]: https://github.com/bytecodealliance/wasmtime/blob/b63c25ae22c53b66904b6988071cfa72c051cfbf/cranelift/codegen/src/isa/riscv64/inst.isle#L1608

Wasmtime GitHub notifications bot (Jul 07 2025 at 10:28):

shashi1687 commented on issue #11183:

Hey everyone, I’d love to own this one—I’ve already dug into the RISC-V lowering and I’m confident I understand what’s happening: under implicit-sret, the ISLE lower_call path only reserves a slot for the first return value, so when it tries to unwrap() a missing register for the second value it panics. My plan is to adjust gen_call_info so stack_ret_space covers all return slots, then emit a post-call gen_load_stack for each extra value, and add a CLIF regression test in clif/tests/isa/riscv64/multi_ret_implicit_sret.clif to prove the fix on both x86_64 and riscv64. I’ve prototyped the change locally, run cargo test -p cranelift-codegen and tools/clif-util test …, and it all checks out. Could you please assign #11183 to me? I’m ready to polish up the PR and get this merged.

Wasmtime GitHub notifications bot (Jul 07 2025 at 10:34):

bjorn3 commented on issue #11183:

I would personally prefer if we just got rid of the implicit-sret behavior entirely: https://github.com/bytecodealliance/wasmtime/issues/9510 This is currently blocked on getting rid of the dependency on it from Wasmtime and cg_clif.

Wasmtime GitHub notifications bot (Jul 07 2025 at 10:52):

shashi1687 commented on issue #11183:

Hello @bjorn3 , thanks for pointing me to the plan in #9510 to remove implicit-sret entirely—I’ve read through that comment and it makes a lot of sense. I’m brand new to the project and this is my first time looking for an issue to work on, so I’m still finding my footing in the codebase. Since #11183 may end up being resolved as part of those larger changes, could you please suggest another issue or area that would be a good fit for a first-time contributor? I’m eager to learn, happy to carve out the time, and would really appreciate any guidance on where to start. Thanks so much for your help!

Wasmtime GitHub notifications bot (Jul 07 2025 at 14:18):

alexcrichton added the cranelift:area:riscv64 label to Issue #11183.

Wasmtime GitHub notifications bot (Jul 07 2025 at 14:53):

shashi1687 edited a comment on issue #11183:

Hello @bjorn3/everyone , thanks for pointing me to the plan in #9510 to remove implicit-sret entirely—I’ve read through that comment and it makes a lot of sense. I’m brand new to the project and this is my first time looking for an issue to work on, so I’m still finding my footing in the codebase. Since #11183 may end up being resolved as part of those larger changes, could you please suggest another issue or area that would be a good fit for a first-time contributor? I’m eager to learn, happy to carve out the time, and would really appreciate any guidance on where to start. Thanks so much for your help!

Wasmtime GitHub notifications bot (Jul 07 2025 at 15:46):

bjorn3 commented on issue #11183:

For Wasmtime I don't know what would be decent first issues (I don't work on Wasmtime myself). For Cranelift I think https://github.com/bytecodealliance/wasmtime/issues/8600 and https://github.com/bytecodealliance/wasmtime/issues/8694 would be good first issues that benefit https://github.com/rust-lang/rustc_codegen_cranelift/ which I wrote. Or for a bit more advanced, https://github.com/bytecodealliance/wasmtime/issues/7916 would be an option.

Last updated: Dec 06 2025 at 06:05 UTC