As you can see, a lot of information is needed for every instruction supported by the code generator, and specifying it all manually would be -unmaintainble, prone to bugs, and tiring to do in the first place. Because we +unmaintainable, prone to bugs, and tiring to do in the first place. Because we are using TableGen, all of the information was derived from the following definition:
@@ -334,8 +332,9 @@ The TableGen types are:To date, these types have been sufficient for describing things that @@ -371,8 +370,11 @@ supported include:
Note that all of the values have rules specifying how they convert to values @@ -627,8 +654,10 @@ Here is an example TableGen fragment that shows this idea:
The name of the resultant definitions has the multidef fragment names appended to them, so this defines ADD_rr, ADD_ri, - SUB_rr, etc. Using a multiclass this way is exactly equivalent to - instantiating the classes multiple times yourself, e.g. by writing:
+ SUB_rr, etc. A defm may inherit from multiple multiclasses, + instantiating definitions from each multiclass. Using a multiclass + this way is exactly equivalent to instantiating the classes multiple + times yourself, e.g. by writing:@@ -656,6 +685,91 @@ Here is an example TableGen fragment that shows this idea:
+A defm can also be used inside a multiclass providing several levels of +multiclass instanciations. +
+ +
+class Instruction<bits<4> opc, string Name> {
+ bits<4> opcode = opc;
+ string name = Name;
+}
+
+multiclass basic_r<bits<4> opc> {
+ def rr : Instruction<opc, "rr">;
+ def rm : Instruction<opc, "rm">;
+}
+
+multiclass basic_s<bits<4> opc> {
+ defm SS : basic_r<opc>;
+ defm SD : basic_r<opc>;
+ def X : Instruction<opc, "x">;
+}
+
+multiclass basic_p<bits<4> opc> {
+ defm PS : basic_r<opc>;
+ defm PD : basic_r<opc>;
+ def Y : Instruction<opc, "y">;
+}
+
+defm ADD : basic_s<0xf>, basic_p<0xf>;
+...
+
+// Results
+def ADDPDrm { ...
+def ADDPDrr { ...
+def ADDPSrm { ...
+def ADDPSrr { ...
+def ADDSDrm { ...
+def ADDSDrr { ...
+def ADDY { ...
+def ADDX { ...
+
++defm declarations can inherit from classes too, the +rule to follow is that the class list must start after the +last multiclass, and there must be at least one multiclass +before them. +
+ +
+class XD { bits<4> Prefix = 11; }
+class XS { bits<4> Prefix = 12; }
+
+class I<bits<4> op> {
+ bits<4> opcode = op;
+}
+
+multiclass R {
+ def rr : I<4>;
+ def rm : I<2>;
+}
+
+multiclass Y {
+ defm SS : R, XD;
+ defm SD : R, XS;
+}
+
+defm Instr : Y;
+
+// Results
+def InstrSDrm {
+ bits<4> opcode = { 0, 0, 1, 0 };
+ bits<4> Prefix = { 1, 1, 0, 0 };
+}
+...
+def InstrSSrr {
+ bits<4> opcode = { 0, 1, 0, 0 };
+ bits<4> Prefix = { 1, 0, 1, 1 };
+}
+
+It's also possible to use "let" expressions inside multiclasses, providing +more ways to factor out commonality from the records, specially if using +several levels of multiclass instanciations. This also avoids the need of using +"let" expressions within subsequent records inside a multiclass.
+ +
+multiclass basic_r<bits<4> opc> {
+ let Predicates = [HasSSE2] in {
+ def rr : Instruction<opc, "rr">;
+ def rm : Instruction<opc, "rm">;
+ }
+ let Predicates = [HasSSE3] in
+ def rx : Instruction<opc, "rx">;
+}
+
+multiclass basic_ss<bits<4> opc> {
+ let IsDouble = 0 in
+ defm SS : basic_r<opc>;
+
+ let IsDouble = 1 in
+ defm SD : basic_r<opc>;
+}
+
+defm ADD : basic_ss<0xf>;
+
+
+
+
+
+
+
+Expressions used by code generator to describe instructions and isel +patterns:
+ +