Stream: cranelift

Topic: RA2: Could not allocate minimal bundle.

Leaves (Sep 04 2024 at 20:15):

So in https://github.com/bytecodealliance/regalloc2/issues/145 , we see that RA2 will give the error TooManyLiveRegs when all registers are clobbered and there are non-fixed uses. What this doesn't bring up is the interaction between different register classes.

If all registers in class Int are clobbered, but there are non-fixed uses in class Vector or Float, we reach the panic at src\ion\process.rs:1266:17 claiming "Could not allocate minimal bundle, but the allocation problem should be possible to solve".

A simple example of a pseudo instruction on x87 that would cause this would be something that clobbers all x86 GPRs(RAX-R15) and then has unfixed uses of a float using xmm registers.

It's not entirely clear to me how this could happen seeing as how the different classes should be entirely disjoint. If someone familiar with RA2 could clue me in then maybe I can take a stab at solving this issue.

Also, in general I'd like more info as to what this panic means.

Chris Fallin (Sep 04 2024 at 20:30):

That whole clump of logic is attempting to help early-out the fuzzer when it generates an impossible problem. However, in general, if you have too many live registers and after splitting into minimal pieces we still can't fit, that's still a user error.

In other words, don't read too much into exactly what the failure mode is: it's still an invalid input to have all regs clobbered and some of those regs required

Chris Fallin (Sep 04 2024 at 20:31):

if you're saying that all regs occupied in on class causes a panic when attempting to allocate another class -- that's surprising, and I'd love a root-cause analysis and fix.

Chris Fallin (Sep 04 2024 at 20:32):

(in general my advice is the same as before: any use of RA2 that is unlike Cranelift's use is at best unsupported, so the level of help here is mostly going to be "you're on your own, happy to review PRs", also because our time is extremely limited, sorry)

Leaves (Sep 04 2024 at 20:41):

A bit more context just in case something jumps out. I have an instruction that is equivalent to a parallel move of the 8 byte value in the lower 8 bytes an XMM register into all 15 available GPRs(15 because RSP is not included). There are 16 XMMs available for allocation in the RegClass::Float class and 15 GPRs available for allocation in RegClass::Int

There are a total of 16 operands, the latter 15 of which completely exhaust and clobber all of the RegClass::Int space.
Operand 1: RegClass::Float, OperandConstraint::Reg, EarlyUse
Operands 2-16: RegClass::Int, OperandConstraint::FixedReg(GPR), LateDef

A function with a single basic block containing only this instruction and a RET causes the panic to be reached, and I am perplexed as to why.

Chris Fallin (Sep 04 2024 at 20:43):

Not sure, sorry, and unable to dedicate the time to debug. If you work it out, happy to take a PR

Leaves (Sep 04 2024 at 20:44):

As long as nothing immediately jumps out at you as to why, I will go dig deep into it. :thumbs_up:

Leaves (Sep 06 2024 at 03:04):

In the process of working on this, I've discovered other reasons this panic occurs.

If there are reused operands, all early uses will have their positions set to after the instruction. However, if the early use is fixed, and there is a fixed late def or clobber of the same register, this panic is triggered.

I'm in the process of only shifting early uses fixed reg uses positions to "after" the instruction if there is not a clobber or late fixed def of the same preg.

Leaves (Sep 06 2024 at 03:07):

my thought process is:

• since there is already a late def or clobber of the preg, the reuse operand won't allocate it.
• the shift of the fixed early use to the late(after) position is creating an unsatisfiable constraint unnecessarily.

Leaves (Sep 06 2024 at 19:08):

submitted this.
https://github.com/bytecodealliance/regalloc2/pull/190

Last updated: Oct 23 2024 at 20:03 UTC