<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/3/2012 12:29 AM, Chris Lattner
      wrote:<br>
    </div>
    <blockquote
      cite="mid:30D9FE67-FE38-42D0-A09F-A60B72C23568@apple.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div>
        <div>On Oct 2, 2012, at 7:23 AM, Matthew Curtis <<a
            moz-do-not-send="true" href="mailto:mcurtis@codeaurora.org">mcurtis@codeaurora.org</a>>
          wrote:</div>
        <blockquote type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          <div bgcolor="#FFFFFF" text="#000000"> I'm adding support for
            <a moz-do-not-send="true"
href="http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435">-ffixed-<reg></a>
            for Hexagon and was wondering if I should do it in such a
            way that other targets get the support as well by default or
            if a given target back-end should have to explicitly opt-in
            for support.<br>
          </div>
        </blockquote>
      </div>
      <br>
      <div>It would be great to have this as a target-indepentent (well,
        obviously the specific register names are target specific, you
        know what I mean) compiler feature.  This is one of the blocking
        issues preventing some portion of the Linux kernel from "just
        working" with LLVM.</div>
      <div><br>
      </div>
      <div>From the design perspective, I think it would make sense to
        represent this in LLVM IR with named metadata (<a
          moz-do-not-send="true"
          href="http://llvm.org/docs/LangRef.html#namedmetadatastructure">http://llvm.org/docs/LangRef.html#namedmetadatastructure</a>)
        like "!llvm.fixedregs".  This could then be picked up by the
        code generator, installed as preallocated registers (Jakob would
        be the one to ask how best to do this).</div>
      <div><br>
      </div>
      <div>If you're not in a huge hurry, an even better way to model
        this is with Bill Wendling's work on generalized function
        attributes.  Our eventual goal is to allow arbitrary
        target-specific function attributes.  Modeling this list as a
        per-function attribute would be much cleaner, and allow
        -ffixed-<reg> to work with LTO.</div>
    </blockquote>
    <br>
    We currently have a working solution that satisfies the needs of our
    internal users, so we're not in a huge hurry.<br>
    <br>
    Depending on the timeline for generalized function attributes, I'd
    like to pursue this as the preferred solution. I will follow-up with
    Bill. <br>
    <br>
    Thanks,<br>
    Matthew Curtis.<br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation</pre>
  </body>
</html>