llvm dev - Apr 2014 - [LLVMdev] Named register variables GNU-style

Richard Smith <richard at metafoo.co.uk> writes:
> On Fri, Mar 28, 2014 at 4:50 AM, Renato Golin <renato.golin at
linaro.org>wrote:
>> On 28 March 2014 11:16, Chandler Carruth <chandlerc at
google.com> wrote:
>> > Just the reserved part.
>>
>> Ok, in that case, I share you concerns.
>>
>> We could easily only implement the reserved ones (stack pointer being
>> the case in hand). If there is any mad reason why allocatable ones
>> should be used (I heard glibc uses R8 for some special things,
haven't
>> confirmed myself), we can discuss this topic later.
>
>
> I'm a bit confused by this. The GCC documentation makes it pretty clear
> that *only* the allocatable registers are suitable for use as global
> register variables (and that things like the stack pointer make no sense
> here). From the doc:
>
> "Defining a global register variable in a certain register reserves
that
> register entirely for this use, at least within the current compilation.
> The register is not allocated for any other purpose in the functions in the
> current compilation, and is not saved and restored by these functions.
> Stores into this register are never deleted even if they appear to be dead,
> but references may be deleted or moved or simplified."
>
> Obviously it's not possible to reserve the stack pointer register
entirely
> for use as a global register variable, and any attempt to do so would be
> abusing the mechanism.
It might not matter, but MIPS linux is one case where a non-allocatable
register is used as a true global variable, rather than as a convienent
way of getting the value of a fixed-purpose register.  The register used
there is $gp, which on bare-metal is usually reserved for small-data and
(in theory) GOT accesses.  Since linux knows it doesn't use either,
it instead uses $gp to hold information about the current thread.

I realise that's probably an unusual case though.

Thanks,
Richard

On 7 April 2014 12:16, Richard Sandiford <rsandifo at linux.vnet.ibm.com>
wrote:
> It might not matter, but MIPS linux is one case where a non-allocatable
> register is used as a true global variable, rather than as a convienent
> way of getting the value of a fixed-purpose register.  The register used
> there is $gp, which on bare-metal is usually reserved for small-data and
> (in theory) GOT accesses.  Since linux knows it doesn't use either,
> it instead uses $gp to hold information about the current thread.
Hi Richard,

I think all cases for named registers are unusual, and that's the
point. I think this is a perfectly valid case for using named
registers, since there is no way in C to represent this logic and bare
metal code might have a heavy use of that register's value.

cheers,
--renato

On 19 April 2014 22:15, Edward Z. Yang <ezyang at mit.edu>
wrote:
> Like the kernel, we use register variables to store thread-local state
> in our garbage collector [1]; on Clang, the lack of this capability
> costs us 30% in overall runtime of all programs.  We can't use inline
> assembly, because that would require us rewriting our entire garbage
> collector (i.e. all code which uses the thread-local state) in inline
> assembly, but this is all code that should be written in C.
Hi Edward,

This is another good reason to have named registers implemented. Many
people replied to my original email with "write inline assembly
instead", but there are cases that doing so would make the project *a
lot* more complex.

> Perhaps this is simply an advertisement for Clang to optimize __thread
> variables in some way further; certainly this would solve our (and other
> folks) problem.
You can certainly propose an optimization that would be beneficial,
and if shown to be safe, you or someone else could implement it in
LLVM or Clang.

cheers,
--renato