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