[llvm-commits] [llvm] r40970 - /llvm/trunk/lib/Target/X86/X86RegisterInfo.td

[Christopher Lamb]

On Aug 9, 2007, at 3:20 PM, Evan Cheng wrote:

>
> On Aug 9, 2007, at 2:45 PM, Christopher Lamb wrote:
>
>> Evan,
>>
>> I don't think that this change is working quite correctly, and may  
>> not be needed, given the way that the subreg code uses those  
>> values. This is currently causing regressions in dejagnu.
>>
>> The register classes in the SubRegClassList are used when new  
>> subreg vregs are created. The key is that the register class be  
>> valid for the register-register mappings in the SubRegSet of the  
>> corresponding index, that is that the all the subregs of the class  
>> must be members of the SubRegClass, not that the sets must be equal.
>>
>> Every subreg of GR16_ is a member of GR8, and every subreg of  
>> GR32_ is properly a member of GR8 or GR16.
> Hi Chris,
>
> Sorry, I am not following. Given GR16_ contains only AX, CX, DX,  
> and BX. How can its subregister class contains GR8 (which includes  
> register like R8B, SIL) that have no relationship with AX, etc.

GR16_ contains only [AX, CX, DX, BX], this means that only valid  
SubRegSets (1) are [AL, CL, DL, BL] which are all members of GR8.  
Constraining the superreg to GR16_ is necessary, but constraining the  
subreg in a new class other than GR8 is not.

> I am ok with backing out the patch for now. But something else  
> seems wrong.

EXTRACT_SUBREG needs to know what register class to use to create new  
vregs during ScheduleDAG. If the register class that EXTRACT_SUBREG  
produces doesn't match the input register class of the consuming  
instruction then you get the errors that your patch created. You have  
EXTRACT_SUBREG producing GR8_ vregs and target instructions expecting  
to use a GR8. To get around this you could have a MOVGR#_toGR#  
instruction placed after every use of EXTRACT_SUBREG, but that'd be  
moving from a subclass to a superclass which can always be eliminated  
(i.e MOV GR8_ -> GR8 is not necessary because all of GR8_ are already  
in GR8).

Hope that helps explain it.

--
Chris

>> On Aug 9, 2007, at 11:05 AM, Evan Cheng wrote:
>>
>>> Author: evancheng
>>> Date: Thu Aug  9 13:05:17 2007
>>> New Revision: 40970
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=40970&view=rev
>>> Log:
>>> GR16_ sub-register class should be GR8_, not GR8. That is, it  
>>> should only be 8-bit registers in 32-bit mode. Ditto for GR32_.
>>>
>>> Modified:
>>>     llvm/trunk/lib/Target/X86/X86RegisterInfo.td
>>>
>>> Modified: llvm/trunk/lib/Target/X86/X86RegisterInfo.td
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ 
>>> X86/X86RegisterInfo.td?rev=40970&r1=40969&r2=40970&view=diff
>>>
>>> ==================================================================== 
>>> ==========
>>> --- llvm/trunk/lib/Target/X86/X86RegisterInfo.td (original)
>>> +++ llvm/trunk/lib/Target/X86/X86RegisterInfo.td Thu Aug  9  
>>> 13:05:17 2007
>>> @@ -417,13 +417,14 @@
>>>  }
>>>
>>>
>>> -// GR16, GR32 subclasses which contain registers that have R8  
>>> sub-registers.
>>> +// GR16, GR32 subclasses which contain registers that have GR8  
>>> sub-registers.
>>>  // These should only be used for 32-bit mode.
>>> +def GR8_ : RegisterClass<"X86", [i8], 8, [AL, CL, DL, BL, AH,  
>>> CH, DH, BH]>;
>>>  def GR16_ : RegisterClass<"X86", [i16], 16, [AX, CX, DX, BX]> {
>>> -  let SubRegClassList = [GR8];
>>> +  let SubRegClassList = [GR8_];
>>>  }
>>>  def GR32_ : RegisterClass<"X86", [i32], 32, [EAX, ECX, EDX, EBX]> {
>>> -  let SubRegClassList = [GR8, GR16];
>>> +  let SubRegClassList = [GR8_, GR16_];
>>>  }
>>>
>>>  // Scalar SSE2 floating point registers.
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> --
>> Christopher Lamb
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070809/1e425314/attachment.html>