I was wondering about whether the PBQP register allocator is likely to be maintained in the future. It’s proving to be a nice way to encode some instruction encoding constraints for an out-of-tree backend we have, but there’s concern about it being abandoned or bitrotting in the future.
Also, if PBQP is likely to lapse out of regular maintenance in the future, is there a simple way to express constraints on allocated registers (such as sharing an encoding, despite being in different register classes) chosen for a particular instruction in the Greedy allocator?
I was wondering about whether the PBQP register allocator is likely to be maintained in the future. It's proving to be a nice way to encode some instruction encoding constraints for an out-of-tree backend we have, but there's concern about it being abandoned or bitrotting in the future.
The PBQP allocator is not going away and in particular Lang actively maintains it when need be.
Also, if PBQP is likely to lapse out of regular maintenance in the future, is there a simple way to express constraints on allocated registers (such as sharing an encoding, despite being in different register classes) chosen for a particular instruction in the Greedy allocator?
You can use the hint mechanism to express your encoding constraints based on what is already allocated. See TargetRegisterInfo::getRegAllocationHints.
PBQP hasn’t received a lot of attention recently, but that’s due to the odd combination of (a) it being fairly robust and isolated (and so not much of a maintenance burden) and (b) it having few users.
I think you should feel free to use it – I don’t think it’s going away any time soon. Plus, the more users it has the more interested people may be in improving it further.
If you do encounter any bugs in it please file a bug on bugs.llvm.org and CC me. In my experience the algorithm is simple enough that fixes are usually fairly straightforward.