I've been browsing the cranelift code and I noticed the following suspicious line:
If I'm reading this right, the opcode for adc r, r/m is wrong – the one for add r, r/m is actually getting used. I tried writing a testcase that triggers this, and iadd_carry causes an ICE because we don't have a lowering rule for it at all. What's going on?
@Maja Kądziołka I'm not sure where you're getting "wrong opcode" from -- the opcode_r here is 0x01 for ADD and 0x11 for ADC, which is correct (see the "Add with CF r64 to r/m64" case)
iadd_carry is not supported and should probably either be removed or filled out; it's an artifact of an older legalization-based approach to "wide" (128-bit) ops. Currently operations on i128s will natively use adc/add pairs during lowering, so all of this is transparent at the CLIF level
opcode_m isn't correct, though!
@Maja Kądziołka ah, yes, that's right; we haven't hit this because we don't use the add-to-memory form of adc (or sbb) at all. If you'd like, I'm happy to review a PR fixing that and adding emit-tests to cover.
And to your second question and if you're feeling ambitious, removing iadd_carryand isub_borrow from Cranelift too; it looks like they only appear in the CLIF interpreter and in some interpreter-only runtests
Last updated: Dec 06 2025 at 06:05 UTC