[cfe-dev] A question on register allocation

[David Chisnall via cfe-dev]

On 5 Oct 2015, at 19:56, Joachim Durchholz via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Just for the record, I'm seeing another use case beyond operating systems: Virtual machines, runtimes for languages that do not put much value on an easy C interface.
> 
> That's still a pretty short list of use cases.
> It could be pretty big for each use case. I guess operating system coders tend to have a specialist for each architecture anyway, and can do better than a compiler could; I'm not so sure for VM and runtime coders.
> 
> OT3H it may be that to make good use of a register, you need to know so much about the architecture that you always can do better than the compiler anyway. Is that a reasonable assumption?

I’m not sure it is a reasonable assumption.  There’s often some benefit in ensuring that a particular register holds a known value in some custom language code.  I believe that either the Haskell of Erlang calling conventions have this property - some registers are designated as having special language semantics and must be both preserved across calls and not clobbered by a call.  The FFI code is responsible for ensuring that these register values are saved across calls to foreign code and set on calls from foreign code.

Even in C, it’s useful to be able to reserve these sometimes.  For example, being able to reserve a register for a stack canary (and have the run-time linker set up interworking stubs that resets it from a global when calling out to code that doesn’t support this).  The SafeStack work would also have benefitted from being able to reserve a register to hold the location of the other stack.

I’m not convinced that the C builtins are particularly useful, but there are a number of cases where the LLVM IR intrinsics would be.

Just because you want to reserve one register for some frequently-accessed global state doesn’t mean that you don’t want to use all of the rest of the LLVM infrastructure.

David