[llvm-dev] [RFC] Allocatable Global Register Variables for ARM

[Friedman, Eli via llvm-dev]

On 12/21/2018 8:08 AM, Carey Williams via llvm-dev wrote:
> Hi all,
>
> This is a RFC on support for Global Register Variables in the Arm backend.
>
> Whilst there has been some prior discussion about whether or not LLVM 
> should (or even needs to) support global register variables,
> today there seems to be a good measure of support for this in both 
> Clang+LLVM (although it is currently limited to SP).
> When most of this support landed there was some concern expressed 
> around the difficulty of extending it to cover allocatable registers.
> We have been looking at building atop of this current support to 
> provide that ability to reserve allocatable registers.
>
> Our primary (bare-metal) use-cases for such support are:
>
>     1. Holding pointers for frequently-accessed data.
>     2. Placement of secure values (e.g. checksums) in specific 
> registers to prevent them from being written out to main memory.


As a side-note, you might want to check that prologue/epilogue emission 
won't emit a PUSH/POP that refers to a register reserved this way; we 
sometimes add an "extra" register to align the stack.


>
> This proposal aims to provide support for using r4-r11 as global 
> register variables. This involves adding them to the reserved register set
> and preventing them from being callee-saved. We have deliberately 
> tried to avoid registers that have a distinct ABI/AAPCS use,
> such as call-clobbered registers, LR and PC etc. Naturally the current 
> support for the stack-pointer remains.


Restricting this specifically to r4-r11 definitely makes sense; allowing 
other registers would be hard.


> r7, r11 and r9 at least are special cases, and are mentioned in more 
> detail below.
>
> Clang Changes
> ----------------------
> The main proposed functional change to Clang is the tracking of global 
> register variable declarations via module flags.
> Each declaration in a translation unit such as "register unsigned int 
> foo __asm("r4");", will be mapped by the front-end to a module flag.
>
> e.g.
> ---
> !{i32 1, !"fixed_reg.foo", !"r4"}
> ---
>
> This is achieved via a modification to CodeGenModule::EmitGlobal. In 
> addition, there are some changes relating
> to specifying valid global registers (by adding an Arm override for 
> isValidGlobalRegister),
>
> Draft Patch: https://reviews.llvm.org/D56003 
> <https://reviews.llvm.org/D56003>


Why did you decide to use global metadata here?  For AArch64, we use a 
target feature instead, to implement roughly equivalent functionality 
(the reserve-x18 feature, to implement -ffixed-x18).


Making a global register declaration have side-effects never made sense, 
IMO; on the surface, it's using variable declaration syntax, but in 
reality it's actually changing the ABI rules for the whole file.  I 
would prefer to support -ffixed-r4, and never allow global register 
declarations to modify the ABI. This subset should be compatible with 
gcc, as far as I know.


(Compiler flags that affect the ABI are easy to misuse, but clang and 
gcc have a long tradition of flags which change the ABI, so it's not 
really worse than what we already do.)


>
> A Note on r7, r11 and r9
> ----------------------------------
> Whilst generally considered allocatable, these registers can on 
> occasion be reserved for other purposes.
> As frame pointers, in the case of r7, and r11, and via -ffixed-r9 (or 
> -frwpi), in the case of r9.
>
> The attached patches do not currently provide any mitigations against 
> these cases.
> Options could range from disallowing these registers entirely, to 
> throwing warnings or
> trying to catch and error in the correct scenarios (e.g. usage 
> -ffixed-r9 when r9 is declared as a global reg variable).


We probably want to emit an error here, to avoid confusion.


-Eli


-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181221/f1143422/attachment.html>