<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>