[LLVMdev] Named Register Implementation

Renato Golin renato.golin at linaro.org
Sat Mar 29 07:27:33 PDT 2014


On 29 March 2014 13:38, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> I disagree. It is the *easy* part to get many known users to work. This
> includes a bunch of kernels, Lisp implementations etc. The rest can be
> implemented on top by hand using inline asm, so this is the crucial
> part.

Let me re-phrase my opinion...

>From all discussions on the LLVM list, the one that has shown more
consistently as a problem was the reservation of allocatable
registers.

Some background...

My original intent was to be able to support the kernel unwinding
code. There was a discussion, in which we agree that for that a
building stack_pointer would do. But the GCC community has voiced two
concerns: there is already a feature for that widely in use, and that
feature is more generic.

Back to the LLVM list, people were concerned with the implementation
and semantics of reserving allocatable registers (yes, we do reserve
some of them specially here and there, but this is a generic
user-driven module-local reservation mechanism, which can put an
unknown strain on the register allocator. Folks agreed, then that a
two step implementation would make sense, given the original
objectives: first for non-allocatable registers, then a register
allocation mechanism could be introduced.

I agree that, to make it work like the GCC, reserving registers would
be the first thing to implement, but we're not going to support the
whole shebang from start, so we can start small. For specifically the
non-allocatable ones, named register is as good as the builtin, and
that would mean no changes to code that already use it would be
necessary, which is always a win.

The plan...

0. Map all uses of named register in the kernel: seem to be
non-allocatable registers only.
1. Implement named registers for non-allocatable registers
2. Map uses of allocatable registers (libs, dynamic languages,
kernels) and make sure there is no other way to do that.
2.a. If there is, do that.
2.b. If not, implement register reservation and expand named register
for those classes (this is contentious and why I'm avoiding it for
now)

cheers,
--renato



More information about the llvm-dev mailing list