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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________
llvm-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
