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

[Bruce Hoult via llvm-dev]

Why not do it the other way around?

Mark Y as reserved, and then at the end of the function if there was
exactly one spill then put that variable in Y instead.

If there were no spills then you lost nothing by reserving Y. If there were
more than one then you need Y for this stack adjustment. So exactly one
spill is the only case where you lost anything by reserving Y.

Which is probably pretty rare, to be honest.

On Mon, May 1, 2017 at 6:27 AM, 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
>
> 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?
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170501/b89a0b7f/attachment.html>