<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/21/2018 8:08 AM, Carey Williams
via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DB6PR08MB28062E78D6443D7F8C58920681B80@DB6PR08MB2806.eurprd08.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
<div>Hi all,<br>
<br>
This is a RFC on support for Global Register Variables in
the Arm backend.<br>
<br>
Whilst there has been some prior discussion about whether or
not LLVM should (or even needs to) support global register
variables,<br>
today there seems to be a good measure of support for this
in both Clang+LLVM (although it is currently limited to SP).<br>
When most of this support landed there was some concern
expressed around the difficulty of extending it to cover
allocatable registers.<br>
We have been looking at building atop of this current
support to provide that ability to reserve allocatable
registers.<br>
<br>
Our primary (bare-metal) use-cases for such support are:<br>
<br>
1. Holding pointers for frequently-accessed data.<br>
2. Placement of secure values (e.g. checksums) in
specific registers to prevent them from being written out to
main memory.<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DB6PR08MB28062E78D6443D7F8C58920681B80@DB6PR08MB2806.eurprd08.prod.outlook.com">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
<div>
<br>
This proposal aims to provide support for using r4-r11 as
global register variables. This involves adding them to the
reserved register set<br>
and preventing them from being callee-saved. We have
deliberately tried to avoid registers that have a distinct
ABI/AAPCS use,<br>
such as call-clobbered registers, LR and PC etc. Naturally
the current support for the stack-pointer remains.<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Restricting this specifically to r4-r11 definitely makes sense;
allowing other registers would be hard.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DB6PR08MB28062E78D6443D7F8C58920681B80@DB6PR08MB2806.eurprd08.prod.outlook.com">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
<div>
r7, r11 and r9 at least are special cases, and are mentioned
in more detail below.<br>
<br>
Clang Changes<br>
<span>----------------------</span><br>
The main proposed functional change to Clang is the tracking
of global register variable declarations via module flags.<br>
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.<br>
<br>
e.g.<br>
---<br>
!{i32 1, !"fixed_reg.foo", !"r4"}<br>
---<br>
<br>
This is achieved via a modification to
CodeGenModule::EmitGlobal. In addition, there are some
changes relating<br>
to specifying valid global registers (by adding an Arm
override for isValidGlobalRegister),<br>
<br>
Draft Patch: <a href="https://reviews.llvm.org/D56003"
target="_blank" rel="noopener noreferrer"
class="x_OWAAutoLink" moz-do-not-send="true">
https://reviews.llvm.org/D56003</a><br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>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).</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>(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.)<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:DB6PR08MB28062E78D6443D7F8C58920681B80@DB6PR08MB2806.eurprd08.prod.outlook.com">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt;
color:rgb(0,0,0);
font-family:Calibri,Helvetica,sans-serif,"EmojiFont","Apple
Color Emoji","Segoe UI
Emoji",NotoColorEmoji,"Segoe UI
Symbol","Android Emoji",EmojiSymbols">
<div>
<div>
<br>
A Note on r7, r11 and r9<br>
<span>----------------------</span>------------<br>
Whilst generally considered allocatable, these registers can
on occasion be reserved for other purposes.<br>
As frame pointers, in the case of r7, and r11, and via
-ffixed-r9 (or -frwpi), in the case of r9.<br>
<br>
The attached patches do not currently provide any
mitigations against these cases.<br>
Options could range from disallowing these registers
entirely, to throwing warnings or<br>
trying to catch and error in the correct scenarios (e.g.
usage -ffixed-r9 when r9 is declared as a global reg
variable).<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>We probably want to emit an error here, to avoid confusion.<br>
</p>
<p><br>
</p>
<p>-Eli<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>