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.
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
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.
(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)
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.
Not sure, sorry, and unable to dedicate the time to debug. If you work it out, happy to take a PR
As long as nothing immediately jumps out at you as to why, I will go dig deep into it. :thumbs_up:
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.
my thought process is:
submitted this.
https://github.com/bytecodealliance/regalloc2/pull/190
Last updated: Dec 23 2024 at 12:05 UTC