[LLVMdev] getMinimalPhysRegClass

[reed kotler]

On 05/14/2012 04:27 PM, Owen Anderson wrote:
> Reed,
>
> On May 14, 2012, at 3:45 PM, reed kotler <rkotler at mips.com 
> <mailto: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
I fixed everything per Jakobs suggestion. Am testing and will submit a 
patch later tonight.

The root of the problem is something that Jakob pointed out earlier
but I did not understand at the time.

The comparisons we do against register class are incorrect and should be 
of the alternate
form that Jakob suggests. We were just lucky that we did not have 
problems from that.

The fact that Mips16 is having problems is just luck; because we could 
just as well have had them
with Mips32 or Mips64 had we defined the register sets slightly differently.

Thanks for the help.

Reed


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