[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
Let me look again. I see your point.

Maybe I did not understand his response.

Reed

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