Cranelift: unexpected panic on riscv64: called `Option::unwrap()` on a `None` value

[akldc]

.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

[bjorn3]

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

[primoly]

This is caused by the RISC-V lowering of select_spectre_guard calling rv_and and rv_andn with FReg (x and y),¹ but they each expect two XReg.²³

Footnotes

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 ↩

[shashforge]

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.

[bjorn3]

I would personally prefer if we just got rid of the implicit-sret behavior entirely: #9510 This is currently blocked on getting rid of the dependency on it from Wasmtime and cg_clif.

[shashforge]

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!

[bjorn3]

For Wasmtime I don't know what would be decent first issues (I don't work on Wasmtime myself). For Cranelift I think #8600 and #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, #7916 would be an option.