[LLVMdev] [PATCH] RegScavenger::scavengeRegister

[Jakob Stoklund Olesen]

On Mar 25, 2013, at 1:41 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:

> Hi Jakob,
> 
> I believe Hal is trying to enable register scavenger to find two (or more) registers that can be used as temporaries.
> 
> One problem I see with this approach is that, if you use register scavenger during PEI, you will have to pessimistically set aside two emergency spill slots before you call scavengeRegister, even if it turns out you only need one. Having an extra stack slot might not be a big problem, but still it is nice if we can avoid allocating a slot unnecessarily.
> 
> I probably won't need these pseudo instructions that are expanded post-RA in the first place if I can tell the register allocators to spill accumulator registers to general purpose integer registers instead of directly to stack and disallow copying between accumulator registers. But I guess that is a much more difficult problem to solve. Is that right?

That depends.

The register allocator can spill across register classes, but it calls the functionality "live range splitting" and "register class inflation". Here's how you enable it:

- Define a union register class that contains both CPU64Regs and ACRegs.

- Implement TRI::getLargestLegalSuperClass(), and return the new union register class when asked about CPU64Regs or ACRegs (or their sub-classes).

- Teach TII::copyPhysReg() to handle the cross-class copies.

- Teach TII::storeRegToStackSlot() to constrain the register class to CPU64Regs when asked to spill a virtual register from the union register class.

This will use cross-class spilling in most cases, but unfortunately we can't guarantee that an ACRegs virtual register will never be spilled. This just makes it much less likely to happen.

Targets are still required to be able to spill all legal register classes.


Instead of scavenging for registers during pseudo-expansion, I would like to make it possible to create new virtual registers during spilling. The plan is to give TII::storeRegToStackSlot() permission to:

- Insert multiple instructions at the provided iterator, and

- Create new virtual registers, possibly from different register classes.

I think that functionality would solve your problems, right?

The general idea is that the scavenger should only be used when it is not possible to determine at RA time if a register is needed. That would typically be because the frame layout is not known yet. If a register is always needed, RA should pick it. It is going to do better than the scavenger.


Can you use Hal's scavenger tricks until we get this functionality added to the register allocators? (Help implementing it is always welcome, of course).

/jakob