<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 05/14/2012 04:27 PM, Owen Anderson wrote:
    <blockquote cite="mid:7FA63B9C-AFF2-4E28-96C1-7C221798C2E8@mac.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Reed,
      <div><br>
        <div>
          <div>On May 14, 2012, at 3:45 PM, reed kotler <<a
              moz-do-not-send="true" href="mailto:rkotler@mips.com">rkotler@mips.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">On 05/14/2012 02:42 PM, Jakob Stoklund
            Olesen wrote:<br>
            <blockquote type="cite">On May 14, 2012, at 2:28 PM, reed
              kotler wrote:<br>
              <br>
              <blockquote type="cite">I'm not using
                getMinimalPhysRegClass. Some target independent code is
                using it.<br>
              </blockquote>
              Probably PEI.<br>
              <br>
              <blockquote type="cite">It makes trouble for us and I
                would like to submit a patch to make it a virtual
                function so that I can override it and make it
                meaningful for Mips, as long as this method still
                exists.<br>
                <br>
                I want to add another register class for Mips16 and
                don't want to define a Mips16 set of registers because
                in reality there is no such thing; MIPS16 is an
                application extension that can exist for either Mips32
                or Mips64 which uses a different instruction encoding.<br>
                <br>
                When I'm compiling for -mips23 -nomips16 I don't want
                the mips16 register class being passed to any functions
                which take such a register class parameter.<br>
                <br>
                As it is right now, it sees mips16 as the minimal size
                class and passes it when I'm compiling for -mips32
                -nomips16<br>
              </blockquote>
              The ARM tGPR register class is the same. It has no
              business showing up in non-Thumb code, but it is
              completely harmless when it does.<br>
              <br>
              My best advice to you is don't try to swim upstream. The
              Liskov substitution principle for register classes is
              deeply ingrained in the LLVM register allocators.<br>
              <br>
              /jakob<br>
              <br>
            </blockquote>
            I guess I can just fix the problem with:<br>
            <br>
              if ((RC == &Mips::CPU16RegsRegClass) && <br>
            !TM.getSubtargetImpl()->inMips16Mode())<br>
                RC = &Mips::CPURegsRegClass;<br>
          </blockquote>
        </div>
        <br>
      </div>
      <div>Can I ask what concrete problem you're seeing?  The ARM
        backend has exactly the same issue: in Thumb1 mode (similar to
        MIPS16), not all GPRs are available.
         Accordingly, getMinimalPhysRegClass() returns tGPR (Thumb GPR)
        for those registers that are accessible in Thumb1 mode.  What
        Jakob's trying to tell you here, and which works in practice for
        the ARM backend, is that <i>this shouldn't matter</i>.  Because
        tGPR is the most restrictive class that contains R0, you know
        that you can safely use that register in any place where a less
        restrictive class is expected.  This is the Liskov substitution
        he mentioned.</div>
      <div><br>
      </div>
      <div>--Owen</div>
    </blockquote>
    I fixed everything per Jakobs suggestion. Am testing and will submit
    a patch later tonight.<br>
    <br>
    The root of the problem is something that Jakob pointed out earlier
    <br>
    but I did not understand at the time.<br>
    <br>
    The comparisons we do against register class are incorrect and
    should be of the alternate<br>
    form that Jakob suggests. We were just lucky that we did not have
    problems from that.<br>
    <br>
    The fact that Mips16 is having problems is just luck; because we
    could just as well have had them<br>
    with Mips32 or Mips64 had we defined the register sets slightly
    differently.<br>
    <br>
    Thanks for the help.<br>
    <br>
    Reed<br>
    <br>
    <br>
  </body>
</html>