[llvm-dev] Marking a register as reserved midway through register allocation

[Matthias Braun via llvm-dev]

> On Apr 30, 2017, at 8:27 PM, Dylan McKay via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hey all,
> 
> I'm attempting to rewrite something that the AVR backend used to support (through an extremely dirty hack that was reverted before the upstreaming of the target).
> 
> The removal of the hack can be seen on GitHub
> 
> https://github.com/avr-llvm/llvm/pull/226/files <https://github.com/avr-llvm/llvm/pull/226/files>
> 
> On the AVR architecture, the stack pointer is not in a standard register, but rather it is a special register which can only be accessed via I/O instructions. In order to implement stack spilling/restoring we need to adjust the stack pointer, which is a problem because we need the value of SP to be in a general purpose register for us to perform arithmetic on it.
> 
> In AVR-GCC, a frame pointer (the 'Y' register) is reserved if there are any spills in a method. This works fine because we can easily perform arithmetic on it and then save it into the real stack pointer via IO instructions.
> 
> I would like to do the same for LLVM. This is tricky however, because we don't know if we need a frame pointer until we've finished register allocation and we've seen a spill.
> 
> In the event that we do see a spill, it is likely that the 'Y' register has already been allocated to some other variable, and so we somehow need to deallocate it and then rewind the regalloc. That is what the old hack above does.
> 
> Is there any way today I can deallocate a register and rewind allocation upon spilling?

This is what most llvm CPU targets do:

- Perform register allocation with all registers available
- PrologEpilogInsertion will determine the final positions for the spill/reload stack slots. If we require additional instructions/registers to actually compute the addresses for the spills/reload then we use vregs for that. [1]
- doScavengeFrameVirtualRegs() will use a RegisterScavenger instance to allocate the vregs: If there is a free register around it is used; Otherwise we do an emergency spill around the vreg lifetime. Targets have to ensure they reserved an emergency spillslot that can be accessed without additional registers in advance if there is a possibility that we need it.

If I understand you correct that strategy does not work on AVR somehow? Then you are probably out of luck and need to extend llvms CodeGen with new strategies.

- Matthias

[1] There's some restrictions on how vregs may be used here, like the defs/uses must stay within the same block.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170501/2f0c440c/attachment.html>