[LLVMdev] getMinimalPhysRegClass

[Owen Anderson]

Reed,

On May 14, 2012, at 3:45 PM, reed kotler <rkotler at mips.com> wrote:

> On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote:
>> On May 14, 2012, at 2:28 PM, reed kotler wrote:
>> 
>>> I'm not using getMinimalPhysRegClass. Some target independent code is using it.
>> Probably PEI.
>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> As it is right now, it sees mips16 as the minimal size class and passes it when I'm compiling for -mips32 -nomips16
>> 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.
>> 
>> 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.
>> 
>> /jakob
>> 
> I guess I can just fix the problem with:
> 
>   if ((RC == &Mips::CPU16RegsRegClass) && 
> !TM.getSubtargetImpl()->inMips16Mode())
>     RC = &Mips::CPURegsRegClass;

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 this shouldn't matter.  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.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120514/789ab78d/attachment.html>