-.. _tablegen:
-
=====================
TableGen Fundamentals
=====================
}
...
-This definition corresponds to a 32-bit register-register add instruction in the
-X86. The string after the '``def``' string indicates the name of the
-record---"``ADD32rr``" 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.
+This definition corresponds to the 32-bit register-register ``add`` instruction
+of the x86 architecture. ``def ADD32rr`` defines a record named
+``ADD32rr``, 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 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 are specific to the needs of the X86 backend, and are only shown as an
+example.
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,
feature of TableGen is that it allows the end-user to define the abstractions
they prefer to use when describing their information.
-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
+Each ``def`` record has a special entry called "NAME". This is the name of the
+record ("``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.
+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 conflicts.
Running TableGen
----------------
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 ``**list**<Register>`` can only contain
- definitions derived from the "``Register``" class).
+ the ``list`` type, for example, to constrain the elements of the list to a
+ common base class (e.g., a ``list<Register>`` can only contain definitions
+ derived from the "``Register``" class).
``dag``
This type represents a nestable directed graph of elements.
``str1#str2``
"#" (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>
+ the operand of the paste.
``!cast<type>(a)``
A symbol of type *type* obtained by looking up the string 'a' in the symbol
table. If the type of 'a' does not match *type*, 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>
+ object defined by a 'def' construct.
``!subst(a, b, c)``
If 'a' and 'b' are of string type or are symbol references, substitute 'b'
TableGen backends
=================
+Until we get a step-by-step HowTo for writing TableGen backends, you can at
+least grab the boilerplate (build system, new files, etc.) from Clang's
+r173931.
+
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 ``TableGen/Record.h``.