alexcrichton transferred Issue #1237:
- What are the steps to reproduce the issue? Can you include a CLIF test case,
ideally reduced with thebugpoint
clif-util command?1. Add the following as legalization: ```rust for &(ty, ty_half) in &[(I64, I32), (I128, I64)] { let inst = ireduce.bind(ty_half).bind(ty); expand.legalize( def!(a = inst(x)), vec![ def!((a, xh) = isplit(x)), ] ) } ``` 2. Try to compile: ``` test run target x86_64 function u0:0() -> i64 system_v { ebb0: v0 = iconst.i64 0 v2 = iconcat v0, v0 v3 = ireduce.i64 v2 return v3 } ; run ```
- What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?I expected the `ireduce` to be legalized to `v3, v999 = isplit v2`. The result however was a verifier error: ``` function u0:0() -> i64 [%rax] system_v { ebb0: [RexOp1pu_id#b8] v0 = iconst.i64 0 [-] v2 = iconcat v0, v0 [Op1ret#c3] return v3 ;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ; error: inst3: v3 is defined by inst2 which has no EBB } ``` The problem is that the following legalization code is generated: ```rust pos.func.dfg.clear_results(inst); let curpos = pos.position(); let srcloc = pos.srcloc(); let (a, xh) = split::isplit(pos.func, cfg, curpos, srcloc, x); let removed = pos.remove_inst(); debug_assert_eq!(removed, inst); return true; ``` The inst results are never attached to an instruction again, nor turned into aliases.
- Which Cranelift version / commit hash / branch are you using? master
Last updated: Dec 23 2024 at 14:03 UTC