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

[Evan Cheng]

On Aug 9, 2007, at 3:36 PM, Christopher Lamb wrote:

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

Ok, so it's the subregister class used for the new vregs created, not  
specifying GR8 being a subregister class of GR16_.

Thanks,

Evan


> --
> 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
>
>
>
> _______________________________________________
> 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/20070810/ea162705/attachment.html>