[LLVMdev] Named register variables GNU-style
Richard Sandiford
rsandifo at linux.vnet.ibm.com
Mon Apr 7 08:16:33 PDT 2014
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
More information about the llvm-dev
mailing list