llvm dev - Mar 2014 - [LLVMdev] Named Register Implementation

On 29 March 2014 10:37, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:
> I'd like to separate this into two different functionalities:
We will. But in reverse order.

> (1) Reserve registers, so that normal allocation won't use them.
> This can be done on a global or function level.
This is the most controversial part of the proposal and is the least
important to make all known cases work. I believe that having access
to registers in that way can only be explained by the inefficiency of
the compiler (for noticing that a register variable should not spill)
and could be easily changed to be a hard rule by a given flag, so that
register pressure still wouldn't spill the variable.

This is similar to named register, but with the additional benefit
that the compiler is free to choose the register, while in the second
case, the user does. It also would work with all standard C code
already available using the `register` keyword. But that's for another
discussion...

> (2) Provide intrinsincs to read/write a given register.
That's the idea right now. Just that. No guarantees. Aperture Labs
kind of science (not Black Mesa).

cheers,
--renato

On Sat, Mar 29, 2014 at 12:21:12PM +0000, Renato Golin
wrote:
> On 29 March 2014 10:37, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
> > I'd like to separate this into two different functionalities:
> 
> We will. But in reverse order.
> 
> 
> > (1) Reserve registers, so that normal allocation won't use them.
> > This can be done on a global or function level.
> 
> This is the most controversial part of the proposal and is the least
> important to make all known cases work.
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.

Joerg

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