"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>TableGen Fundamentals</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
-<div class="doc_title">TableGen Fundamentals</div>
+<h1>TableGen Fundamentals</h1>
+<div>
<ul>
- <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#introduction">Introduction</a>
<ol>
<li><a href="#concepts">Basic concepts</a></li>
<li><a href="#example">An example record</a></li>
<li><a href="#running">Running TableGen</a></li>
- </ol>
- <li><a href="#syntax">TableGen syntax</a></li>
+ </ol></li>
+ <li><a href="#syntax">TableGen syntax</a>
<ol>
- <li><a href="#primitives">TableGen primitives</a></li>
+ <li><a href="#primitives">TableGen primitives</a>
<ol>
<li><a href="#comments">TableGen comments</a></li>
<li><a href="#types">The TableGen type system</a></li>
<li><a href="#values">TableGen values and expressions</a></li>
- </ol>
- <li><a href="#classesdefs">Classes and definitions</a></li>
+ </ol></li>
+ <li><a href="#classesdefs">Classes and definitions</a>
<ol>
<li><a href="#valuedef">Value definitions</a></li>
<li><a href="#recordlet">'let' expressions</a></li>
<li><a href="#templateargs">Class template arguments</a></li>
- </ol>
- <li><a href="#filescope">File scope entities</a></li>
+ <li><a href="#multiclass">Multiclass definitions and instances</a></li>
+ </ol></li>
+ <li><a href="#filescope">File scope entities</a>
<ol>
<li><a href="#include">File inclusion</a></li>
<li><a href="#globallet">'let' expressions</a></li>
- </ol>
- </ol>
- <li><a href="#backends">TableGen backends</a></li>
- <ol>
- <li><a href="#">todo</a></li>
- </ol>
- <li><a href="#codegenerator">The LLVM code generator</a></li>
+ </ol></li>
+ </ol></li>
+ <li><a href="#backends">TableGen backends</a>
<ol>
<li><a href="#">todo</a></li>
- </ol>
+ </ol></li>
</ul>
+</div>
+
+<div class="doc_author">
+ <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
+</div>
<!-- *********************************************************************** -->
-<div class="doc_section"><a name="introduction">Introduction</a></div>
+<h2><a name="introduction">Introduction</a></h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>TableGen's purpose is to help a human develop and maintain records of
domain-specific information. Because there may be a large number of these
<p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
the declarations, and hands the result off to a domain-specific "<a
href="#backends">TableGen backend</a>" for processing. The current major user
-of TableGen is the <a href="#codegenerator">LLVM code generator</a>.
-</p>
+of TableGen is the <a href="CodeGenerator.html">LLVM code generator</a>.</p>
-<p>
-Note that if you work on TableGen much, and use emacs or vim, that you can find
-an emacs "TableGen mode" and a vim language file in <tt>llvm/utils/emacs</tt>
-and <tt>llvm/utils/vim</tt> directory of your LLVM distribution, respectively.
-</p>
-
-</div>
+<p>Note that if you work on TableGen much, and use emacs or vim, that you can
+find an emacs "TableGen mode" and a vim language file in the
+<tt>llvm/utils/emacs</tt> and <tt>llvm/utils/vim</tt> directories of your LLVM
+distribution, respectively.</p>
<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="running">Basic concepts</a>
-</div>
+<h3><a name="concepts">Basic concepts</a></h3>
-<div class="doc_text">
+<div>
-<p>
-TableGen files consist of two key parts: 'classes' and 'definitions', both of
-which are considered 'records'.
-</p>
+<p>TableGen files consist of two key parts: 'classes' and 'definitions', both
+of which are considered 'records'.</p>
-<p>
-<b>TableGen records</b> have a unique name, a list of values, and a list of
-superclasses. The list of values is main data that TableGen builds for each
-record, it is this that holds the domain specific information for the
+<p><b>TableGen records</b> have a unique name, a list of values, and a list of
+superclasses. The list of values is the main data that TableGen builds for each
+record; it is this that holds the domain specific information for the
application. The interpretation of this data is left to a specific <a
href="#backends">TableGen backend</a>, but the structure and format rules are
-taken care of and fixed by TableGen.
-</p>
-
-<p>
-<b>TableGen definitions</b> are the concrete form of 'records'. These generally
-do not have any undefined values, and are marked with the '<tt>def</tt>'
-keyword.
-</p>
-
-<p>
-<b>TableGen classes</b> are abstract records that are used to build and describe
-other records. These 'classes' allow the end-user to build abstractions for
-either the domain they are targetting (such as "Register", "RegisterClass", and
-"Instruction" in the LLVM code generator) or for the implementor to help factor
-out common properties of records (such as "FPInst", which is used to represent
-floating point instructions in the X86 backend). TableGen keeps track of all of
-the classes that are used to build up a definition, so the backend can find all
-definitions of a particular class, such as "Instruction".
-</p>
+taken care of and are fixed by TableGen.</p>
+
+<p><b>TableGen definitions</b> are the concrete form of 'records'. These
+generally do not have any undefined values, and are marked with the
+'<tt>def</tt>' keyword.</p>
+
+<p><b>TableGen classes</b> are abstract records that are used to build and
+describe other records. These 'classes' allow the end-user to build
+abstractions for either the domain they are targeting (such as "Register",
+"RegisterClass", and "Instruction" in the LLVM code generator) or for the
+implementor to help factor out common properties of records (such as "FPInst",
+which is used to represent floating point instructions in the X86 backend).
+TableGen keeps track of all of the classes that are used to build up a
+definition, so the backend can find all definitions of a particular class, such
+as "Instruction".</p>
+
+<p><b>TableGen multiclasses</b> are groups of abstract records that are
+instantiated all at once. Each instantiation can result in multiple
+TableGen definitions. If a multiclass inherits from another multiclass,
+the definitions in the sub-multiclass become part of the current
+multiclass, as if they were declared in the current multiclass.</p>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="example">An example record</a>
-</div>
+<h3><a name="example">An example record</a></h3>
-<div class="doc_text">
+<div>
-<p>
-With no other arguments, TableGen parses the specified file and prints out all
-of the classes, then all of the definitions. This is a good way to see what the
-various definitions expand to fully. Running this on the <tt>X86.td</tt> file
-prints this (at the time of this writing):
-</p>
+<p>With no other arguments, TableGen parses the specified file and prints out
+all of the classes, then all of the definitions. This is a good way to see what
+the various definitions expand to fully. Running this on the <tt>X86.td</tt>
+file prints this (at the time of this writing):</p>
-<p>
+<div class="doc_code">
<pre>
...
-<b>def</b> ADDrr8 { <i>// Instruction X86Inst I2A8 Pattern</i>
- <b>string</b> Name = "add";
+<b>def</b> ADD32rr { <i>// Instruction X86Inst I</i>
<b>string</b> Namespace = "X86";
+ <b>dag</b> OutOperandList = (outs GR32:$dst);
+ <b>dag</b> InOperandList = (ins GR32:$src1, GR32:$src2);
+ <b>string</b> AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
+ <b>list</b><dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
<b>list</b><Register> Uses = [];
- <b>list</b><Register> Defs = [];
+ <b>list</b><Register> Defs = [EFLAGS];
+ <b>list</b><Predicate> Predicates = [];
+ <b>int</b> CodeSize = 3;
+ <b>int</b> AddedComplexity = 0;
<b>bit</b> isReturn = 0;
<b>bit</b> isBranch = 0;
+ <b>bit</b> isIndirectBranch = 0;
+ <b>bit</b> isBarrier = 0;
<b>bit</b> isCall = 0;
- <b>bit</b> isTwoAddress = 1;
+ <b>bit</b> canFoldAsLoad = 0;
+ <b>bit</b> mayLoad = 0;
+ <b>bit</b> mayStore = 0;
+ <b>bit</b> isImplicitDef = 0;
+ <b>bit</b> isConvertibleToThreeAddress = 1;
+ <b>bit</b> isCommutable = 1;
<b>bit</b> isTerminator = 0;
- <b>dag</b> Pattern = (set R8, (plus R8, R8));
- <b>bits</b><8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 0 };
+ <b>bit</b> isReMaterializable = 0;
+ <b>bit</b> isPredicable = 0;
+ <b>bit</b> hasDelaySlot = 0;
+ <b>bit</b> usesCustomInserter = 0;
+ <b>bit</b> hasCtrlDep = 0;
+ <b>bit</b> isNotDuplicable = 0;
+ <b>bit</b> hasSideEffects = 0;
+ <b>bit</b> neverHasSideEffects = 0;
+ InstrItinClass Itinerary = NoItinerary;
+ <b>string</b> Constraints = "";
+ <b>string</b> DisableEncoding = "";
+ <b>bits</b><8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
Format Form = MRMDestReg;
- <b>bits</b><5> FormBits = { 0, 0, 0, 1, 1 };
- ArgType Type = Arg8;
- <b>bits</b><3> TypeBits = { 0, 0, 1 };
+ <b>bits</b><6> FormBits = { 0, 0, 0, 0, 1, 1 };
+ ImmType ImmT = NoImm;
+ <b>bits</b><3> ImmTypeBits = { 0, 0, 0 };
<b>bit</b> hasOpSizePrefix = 0;
- <b>bit</b> printImplicitUses = 0;
+ <b>bit</b> hasAdSizePrefix = 0;
<b>bits</b><4> Prefix = { 0, 0, 0, 0 };
+ <b>bit</b> hasREX_WPrefix = 0;
FPFormat FPForm = ?;
<b>bits</b><3> FPFormBits = { 0, 0, 0 };
}
...
-</pre><p>
-
-<p>
-This definition corresponds to an 8-bit register-register add instruction in the
-X86. The string after the '<tt>def</tt>' string indicates the name of the
-record ("<tt>ADDrr8</tt>" in this case), and the comment at the end of the line
-indicates the superclasses of the definition. The body of the record contains
-all of the data that TableGen assembled for the record, indicating that the
-instruction is part of the "X86" namespace, should be printed as "<tt>add</tt>"
-in the assembly file, it is a two-address instruction, has a particular
-encoding, etc. The contents and semantics of the information in the record is
-specific to the needs of the X86 backend, and is only shown as an example.
-</p>
+</pre>
+</div>
-<p>
-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 are using
-TableGen, all of the information was derived from the following definition:
-</p>
+<p>This definition corresponds to a 32-bit register-register add instruction in
+the X86. The string after the '<tt>def</tt>' string indicates the name of the
+record—"<tt>ADD32rr</tt>" in this case—and the comment at the end of
+the line indicates the superclasses of the definition. The body of the record
+contains all of the data that TableGen assembled for the record, indicating that
+the instruction is part of the "X86" namespace, the pattern indicating how the
+the instruction should be emitted into the assembly file, that it is a
+two-address instruction, has a particular encoding, etc. The contents and
+semantics of the information in the record is specific to the needs of the X86
+backend, and is only shown as an example.</p>
+
+<p>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
+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:</p>
+
+<div class="doc_code">
+<pre>
+let Defs = [EFLAGS],
+ isCommutable = 1, <i>// X = ADD Y,Z --> X = ADD Z,Y</i>
+ isConvertibleToThreeAddress = 1 <b>in</b> <i>// Can transform into LEA.</i>
+def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst),
+ (ins GR32:$src1, GR32:$src2),
+ "add{l}\t{$src2, $dst|$dst, $src2}",
+ [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
+</pre>
+</div>
-<p><pre>
-<b>def</b> ADDrr8 : I2A8<"add", 0x00, MRMDestReg>,
- Pattern<(set R8, (plus R8, R8))>;
-</pre></p>
+<p>This definition makes use of the custom class <tt>I</tt> (extended from the
+custom class <tt>X86Inst</tt>), which is defined in the X86-specific TableGen
+file, to factor out the common features that instructions of its class share. A
+key feature of TableGen is that it allows the end-user to define the
+abstractions they prefer to use when describing their information.</p>
-<p>
-This definition makes use of the custom I2A8 (two address instruction with 8-bit
-operand) class, which is defined in the X86-specific TableGen file to factor out
-the common features that instructions of its class share. A key feature of
-TableGen is that it allows the end-user to define the abstractions they prefer
-to use when describing their information.
-</p>
+<p>Each def record has a special entry called "NAME." This is the
+name of the def ("ADD32rr" above). In the general case def names can
+be formed from various kinds of string processing expressions and NAME
+resolves to the final value obtained after resolving all of those
+expressions. The user may refer to NAME anywhere she desires to use
+the ultimate name of the def. NAME should not be defined anywhere
+else in user code to avoid conflict problems.</p>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="running">Running TableGen</a>
-</div>
+<h3><a name="running">Running TableGen</a></h3>
-<div class="doc_text">
+<div>
-<p>
-TableGen runs just like any other LLVM tool. The first (optional) argument
+<p>TableGen runs just like any other LLVM tool. The first (optional) argument
specifies the file to read. If a filename is not specified, <tt>tblgen</tt>
-reads from standard input.
-</p>
+reads from standard input.</p>
-<p>
-To be useful, one of the <a href="#backends">TableGen backends</a> must be used.
-These backends are selectable on the command line (type '<tt>tblgen --help</tt>'
-for a list). For example, to get a list of all of the definitions that subclass
-a particular type (which can be useful for building up an enum list of these
-records), use the <tt>--print-enums</tt> option:
-</p>
+<p>To be useful, one of the <a href="#backends">TableGen backends</a> must be
+used. These backends are selectable on the command line (type '<tt>tblgen
+-help</tt>' for a list). For example, to get a list of all of the definitions
+that subclass a particular type (which can be useful for building up an enum
+list of these records), use the <tt>-print-enums</tt> option:</p>
-<p><pre>
+<div class="doc_code">
+<pre>
$ tblgen X86.td -print-enums -class=Register
-AH, AL, AX, BH, BL, BP, BX, CH, CL, CX, DH, DI, DL, DX,
-EAX, EBP, EBX, ECX, EDI, EDX, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6,
-SI, SP, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
+AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
+ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
+MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
+R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
+R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
+RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
+XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
+XMM6, XMM7, XMM8, XMM9,
$ tblgen X86.td -print-enums -class=Instruction
-ADCrr32, ADDri16, ADDri16b, ADDri32, ADDri32b, ADDri8, ADDrr16, ADDrr32,
-ADDrr8, ADJCALLSTACKDOWN, ADJCALLSTACKUP, ANDri16, ANDri16b, ANDri32, ANDri32b,
-ANDri8, ANDrr16, ANDrr32, ANDrr8, BSWAPr32, CALLm32, CALLpcrel32, ...
-</pre></p>
+ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
+ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
+ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
+ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
+ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
+</pre>
+</div>
-<p>
-The default backend prints out all of the records, as described <a
-href="#example">above</a>.
-</p>
+<p>The default backend prints out all of the records, as described <a
+href="#example">above</a>.</p>
-<p>
-If you plan to use TableGen for some purpose, you will most likely have to <a
+<p>If you plan to use TableGen, you will most likely have to <a
href="#backends">write a backend</a> that extracts the information specific to
-what you need and formats it in the appropriate way.
-</p>
+what you need and formats it in the appropriate way.</p>
</div>
+</div>
<!-- *********************************************************************** -->
-<div class="doc_section"><a name="syntax">TableGen syntax</a></div>
+<h2><a name="syntax">TableGen syntax</a></h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
-<p>
-TableGen doesn't care about the meaning of data (that is up to the backend to
+<p>TableGen doesn't care about the meaning of data (that is up to the backend to
define), but it does care about syntax, and it enforces a simple type system.
This section describes the syntax and the constructs allowed in a TableGen file.
</p>
-</div>
-
<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="primitives">TableGen primitives</tt></a>
-</div>
+<h3><a name="primitives">TableGen primitives</a></h3>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="comments">TableGen comments</tt></a>
-</div>
+<div>
-<div class="doc_text">
+<!-- -------------------------------------------------------------------------->
+<h4><a name="comments">TableGen comments</a></h4>
+
+<div>
<p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
</div>
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="types">The TableGen type system</a>
+</h4>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="types">The TableGen type system</tt></a>
-</div>
+<div>
-<div class="doc_text">
-<p>
-TableGen files are strongly typed, in a simple (but complete) type-system.
+<p>TableGen files are strongly typed, in a simple (but complete) type-system.
These types are used to perform automatic conversions, check for errors, and to
help interface designers constrain the input that they allow. Every <a
href="#valuedef">value definition</a> is required to have an associated type.
</p>
-<p>
-TableGen supports a mixture of very low-level types (such as <tt>bit</tt>) and
-very high-level types (such as <tt>dag</tt>). This flexibility is what allows
-it to describe a wide range of information conveniently and compactly. The
-TableGen types are:
-</p>
+<p>TableGen supports a mixture of very low-level types (such as <tt>bit</tt>)
+and very high-level types (such as <tt>dag</tt>). This flexibility is what
+allows it to describe a wide range of information conveniently and compactly.
+The TableGen types are:</p>
-<p>
-<ul>
-<li>"<tt><b>bit</b></tt>" - A 'bit' is a boolean value that can hold either 0 or
-1.</li>
+<dl>
+<dt><tt><b>bit</b></tt></dt>
+ <dd>A 'bit' is a boolean value that can hold either 0 or 1.</dd>
-<li>"<tt><b>int</b></tt>" - The 'int' type represents a simple 32-bit integer
-value, such as 5.</li>
+<dt><tt><b>int</b></tt></dt>
+ <dd>The 'int' type represents a simple 32-bit integer value, such as 5.</dd>
-<li>"<tt><b>string</b></tt>" - The 'string' type represents an ordered sequence
-of characters of arbitrary length.</li>
+<dt><tt><b>string</b></tt></dt>
+ <dd>The 'string' type represents an ordered sequence of characters of
+ arbitrary length.</dd>
-<li>"<tt><b>bits</b><n></tt>" - A 'bits' type is a arbitrary, but fixed,
-size integer that is broken up into individual bits. This type is useful
-because it can handle some bits being defined while others are undefined.</li>
+<dt><tt><b>bits</b><n></tt></dt>
+ <dd>A 'bits' type is an arbitrary, but fixed, size integer that is broken up
+ into individual bits. This type is useful because it can handle some bits
+ being defined while others are undefined.</dd>
-<li>"<tt><b>list</b><ty></tt>" - This type represents a list whose
-elements are some other type. The contained type is arbitrary: it can even be
-another list type.</li>
+<dt><tt><b>list</b><ty></tt></dt>
+ <dd>This type represents a list whose elements are some other type. The
+ contained type is arbitrary: it can even be another list type.</dd>
-<li>Class type - Specifying a class name in a type context means that the
-defined value must be a subclass of the specified class. This is useful in
-conjunction with the "list" type, for example, to constrain the elements of the
-list to a common base class (e.g., a <tt><b>list</b><Register></tt> can
-only contain definitions derived from the "<tt>Register</tt>" class).</li>
+<dt>Class type</dt>
+ <dd>Specifying a class name in a type context means that the defined value
+ must be a subclass of the specified class. This is useful in conjunction with
+ the <b><tt>list</tt></b> type, for example, to constrain the elements of the
+ list to a common base class (e.g., a <tt><b>list</b><Register></tt> can
+ only contain definitions derived from the "<tt>Register</tt>" class).</dd>
-<li>"<tt><b>code</b></tt>" - This represents a big hunk of text. NOTE: I don't
-remember why this is distinct from string!</li>
+<dt><tt><b>dag</b></tt></dt>
+ <dd>This type represents a nestable directed graph of elements.</dd>
-<li>"<tt><b>dag</b></tt>" - This type represents a nestable directed graph of
-elements.</li>
-</ul>
-</p>
+<dt><tt><b>code</b></tt></dt>
+ <dd>This represents a big hunk of text. This is lexically distinct from
+ string values because it doesn't require escapeing double quotes and other
+ common characters that occur in code.</dd>
+</dl>
-<p>
-To date, these types have been sufficient for describing things that TableGen
-has been used for, but it is straight-forward to extend this list if needed.
-</p>
+<p>To date, these types have been sufficient for describing things that
+TableGen has been used for, but it is straight-forward to extend this list if
+needed.</p>
</div>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="values">TableGen values and expressions</tt></a>
-</div>
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="values">TableGen values and expressions</a>
+</h4>
<div>
-<p>
-TableGen allows for a pretty reasonable number of different expression forms
+
+<p>TableGen allows for a pretty reasonable number of different expression forms
when building up values. These forms allow the TableGen file to be written in a
natural syntax and flavor for the application. The current expression forms
-supported include:
-</p>
-
-<p><ul>
-<li>? - Uninitialized field.</li>
-<li>0b1001011 - Binary integer value.</li>
-<li>07654321 - Octal integer value (indicated by a leading 0).</li>
-<li>7 - Decimal integer value.</li>
-<li>0x7F - Hexadecimal integer value.</li>
-<li>"foo" - String value.</li>
-<li>[{ .... }] - Code fragment.</li>
-<li>[ X, Y, Z ] - List value.</li>
-<li>{ a, b, c } - Initializer for a "bits<3>" value.</li>
-<li>value - Value reference.</li>
-<li>value{17} - Access to one or more bits of a value.</li>
-<li>DEF - Reference to a record definition.</li>
-<li>X.Y - Reference to the subfield of a value.</li>
-
-<li>(DEF a, b) - A dag value. The first element is required to be a record
-definition, the remaining elements in the list may be arbitrary other values,
-including nested 'dag' values.</li>
-
-</ul></p>
-
-<p>
-Note that all of the values have rules specifying how they convert to to values
-for different types. These rules allow you to assign a value like "7" to a
-"bits<4>" value, for example.
-</p>
-
-
+supported include:</p>
+
+<dl>
+<dt><tt>?</tt></dt>
+ <dd>uninitialized field</dd>
+<dt><tt>0b1001011</tt></dt>
+ <dd>binary integer value</dd>
+<dt><tt>07654321</tt></dt>
+ <dd>octal integer value (indicated by a leading 0)</dd>
+<dt><tt>7</tt></dt>
+ <dd>decimal integer value</dd>
+<dt><tt>0x7F</tt></dt>
+ <dd>hexadecimal integer value</dd>
+<dt><tt>"foo"</tt></dt>
+ <dd>string value</dd>
+<dt><tt>[{ ... }]</tt></dt>
+ <dd>code fragment</dd>
+<dt><tt>[ X, Y, Z ]<type></tt></dt>
+ <dd>list value. <type> is the type of the list
+element and is usually optional. In rare cases,
+TableGen is unable to deduce the element type in
+which case the user must specify it explicitly.</dd>
+<dt><tt>{ a, b, c }</tt></dt>
+ <dd>initializer for a "bits<3>" value</dd>
+<dt><tt>value</tt></dt>
+ <dd>value reference</dd>
+<dt><tt>value{17}</tt></dt>
+ <dd>access to one bit of a value</dd>
+<dt><tt>value{15-17}</tt></dt>
+ <dd>access to multiple bits of a value</dd>
+<dt><tt>DEF</tt></dt>
+ <dd>reference to a record definition</dd>
+<dt><tt>CLASS<val list></tt></dt>
+ <dd>reference to a new anonymous definition of CLASS with the specified
+ template arguments.</dd>
+<dt><tt>X.Y</tt></dt>
+ <dd>reference to the subfield of a value</dd>
+<dt><tt>list[4-7,17,2-3]</tt></dt>
+ <dd>A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from
+ it. Elements may be included multiple times.</dd>
+<dt><tt>(DEF a, b)</tt></dt>
+ <dd>a dag value. The first element is required to be a record definition, the
+ remaining elements in the list may be arbitrary other values, including nested
+ `<tt>dag</tt>' values.</dd>
+<dt><tt>!strconcat(a, b)</tt></dt>
+ <dd>A string value that is the result of concatenating the 'a' and 'b'
+ strings.</dd>
+<dt><tt>str1#str2</tt></dt>
+ <dd>"#" (paste) is a shorthand for !strconcat. It may concatenate
+ things that are not quoted strings, in which case an implicit
+ !cast<string> is done on the operand of the paste.</dd>
+<dt><tt>!cast<type>(a)</tt></dt>
+ <dd>A symbol of type <em>type</em> obtained by looking up the string 'a' in
+the symbol table. If the type of 'a' does not match <em>type</em>, TableGen
+aborts with an error. !cast<string> is a special case in that the argument must
+be an object defined by a 'def' construct.</dd>
+<dt><tt>!subst(a, b, c)</tt></dt>
+ <dd>If 'a' and 'b' are of string type or are symbol references, substitute
+'b' for 'a' in 'c.' This operation is analogous to $(subst) in GNU make.</dd>
+<dt><tt>!foreach(a, b, c)</tt></dt>
+ <dd>For each member 'b' of dag or list 'a' apply operator 'c.' 'b' is a
+dummy variable that should be declared as a member variable of an instantiated
+class. This operation is analogous to $(foreach) in GNU make.</dd>
+<dt><tt>!head(a)</tt></dt>
+ <dd>The first element of list 'a.'</dd>
+<dt><tt>!tail(a)</tt></dt>
+ <dd>The 2nd-N elements of list 'a.'</dd>
+<dt><tt>!empty(a)</tt></dt>
+ <dd>An integer {0,1} indicating whether list 'a' is empty.</dd>
+<dt><tt>!if(a,b,c)</tt></dt>
+ <dd>'b' if the result of 'int' or 'bit' operator 'a' is nonzero,
+ 'c' otherwise.</dd>
+<dt><tt>!eq(a,b)</tt></dt>
+ <dd>'bit 1' if string a is equal to string b, 0 otherwise. This
+ only operates on string, int and bit objects. Use !cast<string> to
+ compare other types of objects.</dd>
+</dl>
+
+<p>Note that all of the values have rules specifying how they convert to values
+for different types. These rules allow you to assign a value like "<tt>7</tt>"
+to a "<tt>bits<4></tt>" value, for example.</p>
</div>
+</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="classesdefs">Classes and definitions</tt></a>
-</div>
+<h3>
+ <a name="classesdefs">Classes and definitions</a>
+</h3>
<div>
-<p>
-As mentioned in the <a href="#concepts">intro</a>, classes and definitions
+
+
<p>As mentioned in the <a href="#concepts">intro</a>, classes and definitions
(collectively known as 'records') in TableGen are the main high-level unit of
information that TableGen collects. Records are defined with a <tt>def</tt> or
<tt>class</tt> keyword, the record name, and an optional list of "<a
-href="templateargs">template arguments</a>". If the record has superclasses,
-they are specified as a comma seperated list that starts with a colon character
-(":"). If <a href="#valuedef">value definitions</a> or <a href="#recordlet">let
-expressions</a> are needed for the class they are enclosed in curly braces
-("{}"), otherwise the record ends with a semicolon. Here is a simple TableGen
-file:
-</p>
+href="#templateargs">template arguments</a>". If the record has superclasses,
+they are specified as a comma separated list that starts with a colon character
+("<tt>:</tt>"). If <a href="#valuedef">value definitions</a> or <a
+href="#recordlet">let expressions</a> are needed for the class, they are
+enclosed in curly braces ("<tt>{}</tt>"); otherwise, the record ends with a
+semicolon.</p>
+
+<p>Here is a simple TableGen file:</p>
-<p><pre>
+<div class="doc_code">
+<pre>
<b>class</b> C { <b>bit</b> V = 1; }
<b>def</b> X : C;
<b>def</b> Y : C {
<b>string</b> Greeting = "hello";
}
-</pre></p>
+</pre>
+</div>
-<p>
-This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of which
-derive from the <tt>C</tt> class. Because of this, they both get the <tt>V</tt>
-bit value. The <tt>Y</tt> definition also gets the Greeting member as well.
-</p>
+<p>This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of
+which derive from the <tt>C</tt> class. Because of this, they both get the
+<tt>V</tt> bit value. The <tt>Y</tt> definition also gets the Greeting member
+as well.</p>
-</div>
+<p>In general, classes are useful for collecting together the commonality
+between a group of records and isolating it in a single place. Also, classes
+permit the specification of default values for their subclasses, allowing the
+subclasses to override them as they wish.</p>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="valuedef">Value definitions</tt></a>
-</div>
+<!---------------------------------------------------------------------------->
+<h4>
+ <a name="valuedef">Value definitions</a>
+</h4>
-<div class="doc_text">
-<p>
-Value definitions define named entries in records. A value must be defined
-before it can be referred to as the operand for another value definition, or
+<div>
+
+<p>Value definitions define named entries in records. A value must be defined
+before it can be referred to as the operand for another value definition or
before the value is reset with a <a href="#recordlet">let expression</a>. A
value is defined by specifying a <a href="#types">TableGen type</a> and a name.
If an initial value is available, it may be specified after the type with an
-equal sign. Value definitions require terminating semicolons.
-</div>
+equal sign. Value definitions require terminating semicolons.</p>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="recordlet">'let' expressions</tt></a>
</div>
-<div class="doc_text">
-<p>
-A record-level let expression is used to change the value of a value definition
-in a record. This is primarily useful when a superclass defines a value that a
-derived class or definitions wants to override. Let expressions consist of the
-'<tt>let</tt>' keyword, followed by a value name, an equal sign ("="), and a new
-value for example, a new class could be added to the example above, redefining
-the <tt>V</tt> field for all of its subclasses:</p>
-
-<p><pre>
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="recordlet">'let' expressions</a>
+</h4>
+
+<div>
+
+<p>A record-level let expression is used to change the value of a value
+definition in a record. This is primarily useful when a superclass defines a
+value that a derived class or definition wants to override. Let expressions
+consist of the '<tt>let</tt>' keyword followed by a value name, an equal sign
+("<tt>=</tt>"), and a new value. For example, a new class could be added to the
+example above, redefining the <tt>V</tt> field for all of its subclasses:</p>
+
+<div class="doc_code">
+<pre>
<b>class</b> D : C { let V = 0; }
<b>def</b> Z : D;
-</pre></p>
+</pre>
+</div>
-<p>
-In this case, the <tt>Z</tt> definition will have a zero value for its "V"
+<p>In this case, the <tt>Z</tt> definition will have a zero value for its "V"
value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
-because the <tt>D</tt> class overrode its value.
-</p>
+because the <tt>D</tt> class overrode its value.</p>
</div>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="templateargs">Class template arguments</tt></a>
-</div>
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="templateargs">Class template arguments</a>
+</h4>
-<div class="doc_text">
-and default values...
+<div>
+
+<p>TableGen permits the definition of parameterized classes as well as normal
+concrete classes. Parameterized TableGen classes specify a list of variable
+bindings (which may optionally have defaults) that are bound when used. Here is
+a simple example:</p>
+
+<div class="doc_code">
+<pre>
+<b>class</b> FPFormat<<b>bits</b><3> val> {
+ <b>bits</b><3> Value = val;
+}
+<b>def</b> NotFP : FPFormat<0>;
+<b>def</b> ZeroArgFP : FPFormat<1>;
+<b>def</b> OneArgFP : FPFormat<2>;
+<b>def</b> OneArgFPRW : FPFormat<3>;
+<b>def</b> TwoArgFP : FPFormat<4>;
+<b>def</b> CompareFP : FPFormat<5>;
+<b>def</b> CondMovFP : FPFormat<6>;
+<b>def</b> SpecialFP : FPFormat<7>;
+</pre>
</div>
+<p>In this case, template arguments are used as a space efficient way to specify
+a list of "enumeration values", each with a "<tt>Value</tt>" field set to the
+specified integer.</p>
+<p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
+useful in conjunction with template arguments. As an example:</p>
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="filescope">File scope entities</tt></a>
+<div class="doc_code">
+<pre>
+<b>class</b> ModRefVal<<b>bits</b><2> val> {
+ <b>bits</b><2> Value = val;
+}
+
+<b>def</b> None : ModRefVal<0>;
+<b>def</b> Mod : ModRefVal<1>;
+<b>def</b> Ref : ModRefVal<2>;
+<b>def</b> ModRef : ModRefVal<3>;
+
+<b>class</b> Value<ModRefVal MR> {
+ <i>// Decode some information into a more convenient format, while providing
+ // a nice interface to the user of the "Value" class.</i>
+ <b>bit</b> isMod = MR.Value{0};
+ <b>bit</b> isRef = MR.Value{1};
+
+ <i>// other stuff...</i>
+}
+
+<i>// Example uses</i>
+<b>def</b> bork : Value<Mod>;
+<b>def</b> zork : Value<Ref>;
+<b>def</b> hork : Value<ModRef>;
+</pre>
+</div>
+
+<p>This is obviously a contrived example, but it shows how template arguments
+can be used to decouple the interface provided to the user of the class from the
+actual internal data representation expected by the class. In this case,
+running <tt>tblgen</tt> on the example prints the following definitions:</p>
+
+<div class="doc_code">
+<pre>
+<b>def</b> bork { <i>// Value</i>
+ <b>bit</b> isMod = 1;
+ <b>bit</b> isRef = 0;
+}
+<b>def</b> hork { <i>// Value</i>
+ <b>bit</b> isMod = 1;
+ <b>bit</b> isRef = 1;
+}
+<b>def</b> zork { <i>// Value</i>
+ <b>bit</b> isMod = 0;
+ <b>bit</b> isRef = 1;
+}
+</pre>
</div>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="include">File inclusion</tt></a>
+<p> This shows that TableGen was able to dig into the argument and extract a
+piece of information that was requested by the designer of the "Value" class.
+For more realistic examples, please see existing users of TableGen, such as the
+X86 backend.</p>
+
</div>
-<div class="doc_text">
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="multiclass">Multiclass definitions and instances</a>
+</h4>
+
+<div>
+
<p>
-TableGen supports the '<tt>include</tt>' token, which textually substitutes the
-specified file in place of the include directive. The filename should be
-specified as a double quoted string immediately after the '<tt>include</tt>'
-keyword. Example:
+While classes with template arguments are a good way to factor commonality
+between two instances of a definition, multiclasses allow a convenient notation
+for defining multiple definitions at once (instances of implicitly constructed
+classes). For example, consider an 3-address instruction set whose instructions
+come in two forms: "<tt>reg = reg op reg</tt>" and "<tt>reg = reg op imm</tt>"
+(e.g. SPARC). In this case, you'd like to specify in one place that this
+commonality exists, then in a separate place indicate what all the ops are.
+</p>
-<p><pre>
- <b>include</b> "foo.td"
-</pre></p>
+<p>
+Here is an example TableGen fragment that shows this idea:
+</p>
+<div class="doc_code">
+<pre>
+<b>def</b> ops;
+<b>def</b> GPR;
+<b>def</b> Imm;
+<b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
+
+<b>multiclass</b> ri_inst<<b>int</b> opc, <b>string</b> asmstr> {
+ def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+ def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+}
+
+<i>// Instantiations of the ri_inst multiclass.</i>
+<b>defm</b> ADD : ri_inst<0b111, "add">;
+<b>defm</b> SUB : ri_inst<0b101, "sub">;
+<b>defm</b> MUL : ri_inst<0b100, "mul">;
+...
+</pre>
</div>
-<!----------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="globallet">'let' expressions</tt></a>
+<p>The name of the resultant definitions has the multidef fragment names
+ appended to them, so this defines <tt>ADD_rr</tt>, <tt>ADD_ri</tt>,
+ <tt>SUB_rr</tt>, 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:</p>
+
+<div class="doc_code">
+<pre>
+<b>def</b> ops;
+<b>def</b> GPR;
+<b>def</b> Imm;
+<b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
+
+<b>class</b> rrinst<<b>int</b> opc, <b>string</b> asmstr>
+ : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+
+<b>class</b> riinst<<b>int</b> opc, <b>string</b> asmstr>
+ : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+
+<i>// Instantiations of the ri_inst multiclass.</i>
+<b>def</b> ADD_rr : rrinst<0b111, "add">;
+<b>def</b> ADD_ri : riinst<0b111, "add">;
+<b>def</b> SUB_rr : rrinst<0b101, "sub">;
+<b>def</b> SUB_ri : riinst<0b101, "sub">;
+<b>def</b> MUL_rr : rrinst<0b100, "mul">;
+<b>def</b> MUL_ri : riinst<0b100, "mul">;
+...
+</pre>
</div>
-<div class="doc_text">
<p>
-"let" expressions at file scope are similar to <a href="#recordlet">"let"
-expressions within a record</a>, except they can specify a value binding for
-multiple records at a time, and may be useful in certain other cases.
-File-scope let expressions are really just another way that TableGen allows the
-end-user to factor out commonality from the records.
+A defm can also be used inside a multiclass providing several levels of
+multiclass instanciations.
</p>
+<div class="doc_code">
+<pre>
+<b>class</b> Instruction<bits<4> opc, string Name> {
+ bits<4> opcode = opc;
+ string name = Name;
+}
+
+<b>multiclass</b> basic_r<bits<4> opc> {
+ <b>def</b> rr : Instruction<opc, "rr">;
+ <b>def</b> rm : Instruction<opc, "rm">;
+}
+
+<b>multiclass</b> basic_s<bits<4> opc> {
+ <b>defm</b> SS : basic_r<opc>;
+ <b>defm</b> SD : basic_r<opc>;
+ <b>def</b> X : Instruction<opc, "x">;
+}
+
+<b>multiclass</b> basic_p<bits<4> opc> {
+ <b>defm</b> PS : basic_r<opc>;
+ <b>defm</b> PD : basic_r<opc>;
+ <b>def</b> Y : Instruction<opc, "y">;
+}
+
+<b>defm</b> ADD : basic_s<0xf>, basic_p<0xf>;
+...
+
+<i>// Results</i>
+<b>def</b> ADDPDrm { ...
+<b>def</b> ADDPDrr { ...
+<b>def</b> ADDPSrm { ...
+<b>def</b> ADDPSrr { ...
+<b>def</b> ADDSDrm { ...
+<b>def</b> ADDSDrr { ...
+<b>def</b> ADDY { ...
+<b>def</b> ADDX { ...
+</pre>
+</div>
+
<p>
-File-scope "let" expressions take a comma-seperated list of bindings to apply,
-and one of more records to bind the values in. Here are some examples:
+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.
</p>
-<p><pre>
-<b>let</b> isTerminator = 1, isReturn = 1 <b>in</b>
- <b>def</b> RET : X86Inst<"ret", 0xC3, RawFrm, NoArg>;
+<div class="doc_code">
+<pre>
+<b>class</b> XD { bits<4> Prefix = 11; }
+<b>class</b> XS { bits<4> Prefix = 12; }
+
+<b>class</b> I<bits<4> op> {
+ bits<4> opcode = op;
+}
+
+<b>multiclass</b> R {
+ <b>def</b> rr : I<4>;
+ <b>def</b> rm : I<2>;
+}
+
+<b>multiclass</b> Y {
+ <b>defm</b> SS : R, XD;
+ <b>defm</b> SD : R, XS;
+}
+
+<b>defm</b> Instr : Y;
+
+<i>// Results</i>
+<b>def</b> InstrSDrm {
+ bits<4> opcode = { 0, 0, 1, 0 };
+ bits<4> Prefix = { 1, 1, 0, 0 };
+}
+...
+<b>def</b> InstrSSrr {
+ bits<4> opcode = { 0, 1, 0, 0 };
+ bits<4> Prefix = { 1, 0, 1, 1 };
+}
+</pre>
+</div>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="filescope">File scope entities</a>
+</h3>
+
+<div>
+
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="include">File inclusion</a>
+</h4>
+
+<div>
+<p>TableGen supports the '<tt>include</tt>' token, which textually substitutes
+the specified file in place of the include directive. The filename should be
+specified as a double quoted string immediately after the '<tt>include</tt>'
+keyword. Example:</p>
+
+<div class="doc_code">
+<pre>
+<b>include</b> "foo.td"
+</pre>
+</div>
+
+</div>
+
+<!-- -------------------------------------------------------------------------->
+<h4>
+ <a name="globallet">'let' expressions</a>
+</h4>
+
+<div>
+
+<p>"Let" expressions at file scope are similar to <a href="#recordlet">"let"
+expressions within a record</a>, except they can specify a value binding for
+multiple records at a time, and may be useful in certain other cases.
+File-scope let expressions are really just another way that TableGen allows the
+end-user to factor out commonality from the records.</p>
+
+<p>File-scope "let" expressions take a comma-separated list of bindings to
+apply, and one or more records to bind the values in. Here are some
+examples:</p>
+
+<div class="doc_code">
+<pre>
+<b>let</b> isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 <b>in</b>
+ <b>def</b> RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
<b>let</b> isCall = 1 <b>in</b>
<i>// All calls clobber the non-callee saved registers...</i>
- <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6] in {
- <b>def</b> CALLpcrel32 : X86Inst<"call", 0xE8, RawFrm, NoArg>;
- <b>def</b> CALLr32 : X86Inst<"call", 0xFF, MRMS2r, Arg32>;
- <b>def</b> CALLm32 : X86Inst<"call", 0xFF, MRMS2m, Arg32>;
+ <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
+ MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
+ XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] <b>in</b> {
+ <b>def</b> CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
+ "call\t${dst:call}", []>;
+ <b>def</b> CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
+ "call\t{*}$dst", [(X86call GR32:$dst)]>;
+ <b>def</b> CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
+ "call\t{*}$dst", []>;
}
-</pre></p>
-
-<p>
-File-scope "let" expressions are often useful when a couple of definitions need
-to be added to several records, and the records do not otherwise need to be
-opened, as in the case with the CALL* instructions above.
-</p>
+</pre>
</div>
+<p>File-scope "let" expressions are often useful when a couple of definitions
+need to be added to several records, and the records do not otherwise need to be
+opened, as in the case with the <tt>CALL*</tt> instructions above.</p>
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="backends">TableGen backends</a></div>
-<!-- *********************************************************************** -->
+<p>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.</p>
-<div class="doc_text">
+<pre class="doc_code">
+<b>multiclass </b>basic_r<bits<4> opc> {
+ <b>let </b>Predicates = [HasSSE2] in {
+ <b>def </b>rr : Instruction<opc, "rr">;
+ <b>def </b>rm : Instruction<opc, "rm">;
+ }
+ <b>let </b>Predicates = [HasSSE3] in
+ <b>def </b>rx : Instruction<opc, "rx">;
+}
-<p>
-How they work, how to write one. This section should not contain details about
-any particular backend, except maybe -print-enums as an example. This should
-highlight the APIs in TableGen/Record.h.
-</p>
+<b>multiclass </b>basic_ss<bits<4> opc> {
+ <b>let </b>IsDouble = 0 in
+ <b>defm </b>SS : basic_r<opc>;
+
+ <b>let </b>IsDouble = 1 in
+ <b>defm </b>SD : basic_r<opc>;
+}
+<b>defm </b>ADD : basic_ss<0xf>;
+</pre>
</div>
+</div>
+
+</div>
<!-- *********************************************************************** -->
-<div class="doc_section"><a name="codegenerator">The LLVM code generator</a></div>
+<h2><a name="codegen">Code Generator backend info</a></h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
-<p>
-This is just a temporary, convenient, place to put stuff about the code
-generator before it gets its own document. This should describe all of the
-tablegen backends used by the code generator and the classes/definitions they
-expect.
-</p>
+<p>Expressions used by code generator to describe instructions and isel
+patterns:</p>
+<dl>
+<dt><tt>(implicit a)</tt></dt>
+ <dd>an implicitly defined physical register. This tells the dag instruction
+ selection emitter the input pattern's extra definitions matches implicit
+ physical register definitions.</dd>
+</dl>
</div>
+<!-- *********************************************************************** -->
+<h2><a name="backends">TableGen backends</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+<p>TODO: How they work, how to write one. This section should not contain
+details about any particular backend, except maybe -print-enums as an example.
+This should highlight the APIs in <tt>TableGen/Record.h</tt>.</p>
+
+</div>
<!-- *********************************************************************** -->
+
<hr>
-<div class="doc_footer">
- <address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
- <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
- <br>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
-</div>
+</address>
</body>
</html>
projects / oota-llvm.git / blobdiff