diff options
Diffstat (limited to 'docs/TableGenFundamentals.rst')
| -rw-r--r-- | docs/TableGenFundamentals.rst | 800 |
1 files changed, 5 insertions, 795 deletions
diff --git a/docs/TableGenFundamentals.rst b/docs/TableGenFundamentals.rst index 4fe4bb9..75e82ae 100644 --- a/docs/TableGenFundamentals.rst +++ b/docs/TableGenFundamentals.rst @@ -2,799 +2,9 @@ TableGen Fundamentals ===================== -.. contents:: - :local: +Moved +===== -Introduction -============ - -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 -records, it is specifically designed to allow writing flexible descriptions and -for common features of these records to be factored out. This reduces the -amount of duplication in the description, reduces the chance of error, and makes -it easier to structure domain specific information. - -The core part of TableGen `parses a file`_, instantiates the declarations, and -hands the result off to a domain-specific `TableGen backend`_ for processing. -The current major user of TableGen is the `LLVM code -generator <CodeGenerator.html>`_. - -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 ``llvm/utils/emacs`` and -``llvm/utils/vim`` directories of your LLVM distribution, respectively. - -.. _intro: - -Basic concepts --------------- - -TableGen files consist of two key parts: 'classes' and 'definitions', both of -which are considered 'records'. - -**TableGen records** 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 `TableGen -backend`_, but the structure and format rules are taken care of and are fixed by -TableGen. - -**TableGen definitions** are the concrete form of 'records'. These generally do -not have any undefined values, and are marked with the '``def``' keyword. - -**TableGen classes** 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". - -**TableGen multiclasses** 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. - -.. _described above: - -An example record ------------------ - -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 ``X86.td`` file prints -this (at the time of this writing): - -.. code-block:: llvm - - ... - def ADD32rr { // Instruction X86Inst I - string Namespace = "X86"; - dag OutOperandList = (outs GR32:$dst); - dag InOperandList = (ins GR32:$src1, GR32:$src2); - string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}"; - list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]; - list<Register> Uses = []; - list<Register> Defs = [EFLAGS]; - list<Predicate> Predicates = []; - int CodeSize = 3; - int AddedComplexity = 0; - bit isReturn = 0; - bit isBranch = 0; - bit isIndirectBranch = 0; - bit isBarrier = 0; - bit isCall = 0; - bit canFoldAsLoad = 0; - bit mayLoad = 0; - bit mayStore = 0; - bit isImplicitDef = 0; - bit isConvertibleToThreeAddress = 1; - bit isCommutable = 1; - bit isTerminator = 0; - bit isReMaterializable = 0; - bit isPredicable = 0; - bit hasDelaySlot = 0; - bit usesCustomInserter = 0; - bit hasCtrlDep = 0; - bit isNotDuplicable = 0; - bit hasSideEffects = 0; - bit neverHasSideEffects = 0; - InstrItinClass Itinerary = NoItinerary; - string Constraints = ""; - string DisableEncoding = ""; - bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 }; - Format Form = MRMDestReg; - bits<6> FormBits = { 0, 0, 0, 0, 1, 1 }; - ImmType ImmT = NoImm; - bits<3> ImmTypeBits = { 0, 0, 0 }; - bit hasOpSizePrefix = 0; - bit hasAdSizePrefix = 0; - bits<4> Prefix = { 0, 0, 0, 0 }; - bit hasREX_WPrefix = 0; - FPFormat FPForm = ?; - bits<3> FPFormBits = { 0, 0, 0 }; - } - ... - -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, -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: - -.. code-block:: llvm - - let Defs = [EFLAGS], - isCommutable = 1, // X = ADD Y,Z --> X = ADD Z,Y - isConvertibleToThreeAddress = 1 in // Can transform into LEA. - 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))]>; - -This definition makes use of the custom class ``I`` (extended from the custom -class ``X86Inst``), 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. - -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 conflicts. - -Running TableGen ----------------- - -TableGen runs just like any other LLVM tool. The first (optional) argument -specifies the file to read. If a filename is not specified, ``llvm-tblgen`` -reads from standard input. - -To be useful, one of the `TableGen backends`_ must be used. These backends are -selectable on the command line (type '``llvm-tblgen -help``' 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 -``-print-enums`` option: - -.. code-block:: bash - - $ llvm-tblgen X86.td -print-enums -class=Register - 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, - - $ llvm-tblgen X86.td -print-enums -class=Instruction - 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, ... - -The default backend prints out all of the records, as `described above`_. - -If you plan to use TableGen, you will most likely have to `write a backend`_ -that extracts the information specific to what you need and formats it in the -appropriate way. - -.. _parses a file: - -TableGen syntax -=============== - -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. - -TableGen primitives -------------------- - -TableGen comments -^^^^^^^^^^^^^^^^^ - -TableGen supports BCPL style "``//``" comments, which run to the end of the -line, and it also supports **nestable** "``/* */``" comments. - -.. _TableGen type: - -The TableGen type system -^^^^^^^^^^^^^^^^^^^^^^^^ - -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 `value -definition`_ is required to have an associated type. - -TableGen supports a mixture of very low-level types (such as ``bit``) and very -high-level types (such as ``dag``). This flexibility is what allows it to -describe a wide range of information conveniently and compactly. The TableGen -types are: - -``bit`` - A 'bit' is a boolean value that can hold either 0 or 1. - -``int`` - The 'int' type represents a simple 32-bit integer value, such as 5. - -``string`` - The 'string' type represents an ordered sequence of characters of arbitrary - length. - -``bits<n>`` - 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. - -``list<ty>`` - This type represents a list whose elements are some other type. The - contained type is arbitrary: it can even be another list type. - -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). - -``dag`` - This type represents a nestable directed graph of elements. - -``code`` - This represents a big hunk of text. This is lexically distinct from string - values because it doesn't require escaping double quotes and other common - characters that occur in code. - -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. - -.. _TableGen expressions: - -TableGen values and expressions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -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: - -``?`` - uninitialized field - -``0b1001011`` - binary integer value - -``07654321`` - octal integer value (indicated by a leading 0) - -``7`` - decimal integer value - -``0x7F`` - hexadecimal integer value - -``"foo"`` - string value - -``[{ ... }]`` - code fragment - -``[ X, Y, Z ]<type>`` - 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. - -``{ a, b, c }`` - initializer for a "bits<3>" value - -``value`` - value reference - -``value{17}`` - access to one bit of a value - -``value{15-17}`` - access to multiple bits of a value - -``DEF`` - reference to a record definition - -``CLASS<val list>`` - reference to a new anonymous definition of CLASS with the specified template - arguments. - -``X.Y`` - reference to the subfield of a value - -``list[4-7,17,2-3]`` - A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from it. - Elements may be included multiple times. - -``foreach <var> = [ <list> ] in { <body> }`` - -``foreach <var> = [ <list> ] in <def>`` - Replicate <body> or <def>, replacing instances of <var> with each value - in <list>. <var> is scoped at the level of the ``foreach`` loop and must - not conflict with any other object introduced in <body> or <def>. Currently - only ``def``\s are expanded within <body>. - -``foreach <var> = 0-15 in ...`` - -``foreach <var> = {0-15,32-47} in ...`` - Loop over ranges of integers. The braces are required for multiple ranges. - -``(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. - -``!strconcat(a, b)`` - A string value that is the result of concatenating the 'a' and 'b' strings. - -``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. - -``!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. - -``!subst(a, b, c)`` - 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. - -``!foreach(a, b, c)`` - 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. - -``!head(a)`` - The first element of list 'a.' - -``!tail(a)`` - The 2nd-N elements of list 'a.' - -``!empty(a)`` - An integer {0,1} indicating whether list 'a' is empty. - -``!if(a,b,c)`` - 'b' if the result of 'int' or 'bit' operator 'a' is nonzero, 'c' otherwise. - -``!eq(a,b)`` - '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. - -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 "``7``" -to a "``bits<4>``" value, for example. - -Classes and definitions ------------------------ - -As mentioned in the `intro`_, 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 ``def`` or ``class`` keyword, the record -name, and an optional list of "`template arguments`_". If the record has -superclasses, they are specified as a comma separated list that starts with a -colon character ("``:``"). If `value definitions`_ or `let expressions`_ are -needed for the class, they are enclosed in curly braces ("``{}``"); otherwise, -the record ends with a semicolon. - -Here is a simple TableGen file: - -.. code-block:: llvm - - class C { bit V = 1; } - def X : C; - def Y : C { - string Greeting = "hello"; - } - -This example defines two definitions, ``X`` and ``Y``, both of which derive from -the ``C`` class. Because of this, they both get the ``V`` bit value. The ``Y`` -definition also gets the Greeting member as well. - -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. - -.. _value definition: -.. _value definitions: - -Value definitions -^^^^^^^^^^^^^^^^^ - -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 `let expression`_. A value is defined by -specifying a `TableGen type`_ 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. - -.. _let expression: -.. _let expressions: -.. _"let" expressions within a record: - -'let' expressions -^^^^^^^^^^^^^^^^^ - -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 -'``let``' 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 ``V`` field for all of its subclasses: - -.. code-block:: llvm - - class D : C { let V = 0; } - def Z : D; - -In this case, the ``Z`` definition will have a zero value for its ``V`` value, -despite the fact that it derives (indirectly) from the ``C`` class, because the -``D`` class overrode its value. - -.. _template arguments: - -Class template arguments -^^^^^^^^^^^^^^^^^^^^^^^^ - -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: - -.. code-block:: llvm - - class FPFormat<bits<3> val> { - bits<3> Value = val; - } - def NotFP : FPFormat<0>; - def ZeroArgFP : FPFormat<1>; - def OneArgFP : FPFormat<2>; - def OneArgFPRW : FPFormat<3>; - def TwoArgFP : FPFormat<4>; - def CompareFP : FPFormat<5>; - def CondMovFP : FPFormat<6>; - def SpecialFP : FPFormat<7>; - -In this case, template arguments are used as a space efficient way to specify a -list of "enumeration values", each with a "``Value``" field set to the specified -integer. - -The more esoteric forms of `TableGen expressions`_ are useful in conjunction -with template arguments. As an example: - -.. code-block:: llvm - - class ModRefVal<bits<2> val> { - bits<2> Value = val; - } - - def None : ModRefVal<0>; - def Mod : ModRefVal<1>; - def Ref : ModRefVal<2>; - def ModRef : ModRefVal<3>; - - class Value<ModRefVal MR> { - // Decode some information into a more convenient format, while providing - // a nice interface to the user of the "Value" class. - bit isMod = MR.Value{0}; - bit isRef = MR.Value{1}; - - // other stuff... - } - - // Example uses - def bork : Value<Mod>; - def zork : Value<Ref>; - def hork : Value<ModRef>; - -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 ``llvm-tblgen`` on the example prints the following definitions: - -.. code-block:: llvm - - def bork { // Value - bit isMod = 1; - bit isRef = 0; - } - def hork { // Value - bit isMod = 1; - bit isRef = 1; - } - def zork { // Value - bit isMod = 0; - bit isRef = 1; - } - -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. - -Multiclass definitions and instances -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -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: "``reg = reg op reg``" and "``reg = reg op imm``" -(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. - -Here is an example TableGen fragment that shows this idea: - -.. code-block:: llvm - - def ops; - def GPR; - def Imm; - class inst<int opc, string asmstr, dag operandlist>; - - multiclass ri_inst<int opc, string 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)>; - } - - // Instantiations of the ri_inst multiclass. - defm ADD : ri_inst<0b111, "add">; - defm SUB : ri_inst<0b101, "sub">; - defm MUL : ri_inst<0b100, "mul">; - ... - -The name of the resultant definitions has the multidef fragment names appended -to them, so this defines ``ADD_rr``, ``ADD_ri``, ``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: - -.. code-block:: llvm - - def ops; - def GPR; - def Imm; - class inst<int opc, string asmstr, dag operandlist>; - - class rrinst<int opc, string asmstr> - : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"), - (ops GPR:$dst, GPR:$src1, GPR:$src2)>; - - class riinst<int opc, string asmstr> - : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"), - (ops GPR:$dst, GPR:$src1, Imm:$src2)>; - - // Instantiations of the ri_inst multiclass. - def ADD_rr : rrinst<0b111, "add">; - def ADD_ri : riinst<0b111, "add">; - def SUB_rr : rrinst<0b101, "sub">; - def SUB_ri : riinst<0b101, "sub">; - def MUL_rr : rrinst<0b100, "mul">; - def MUL_ri : riinst<0b100, "mul">; - ... - -A ``defm`` can also be used inside a multiclass providing several levels of -multiclass instanciations. - -.. code-block:: llvm - - 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. - -.. code-block:: llvm - - 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 }; - } - -File scope entities -------------------- - -File inclusion -^^^^^^^^^^^^^^ - -TableGen supports the '``include``' 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 '``include``' keyword. -Example: - -.. code-block:: llvm - - include "foo.td" - -'let' expressions -^^^^^^^^^^^^^^^^^ - -"Let" expressions at file scope are similar to `"let" expressions within a -record`_, 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. - -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: - -.. code-block:: llvm - - let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in - def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>; - - let isCall = 1 in - // All calls clobber the non-callee saved registers... - let 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] in { - def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops), - "call\t${dst:call}", []>; - def CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops), - "call\t{*}$dst", [(X86call GR32:$dst)]>; - def CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops), - "call\t{*}$dst", []>; - } - -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. - -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. - -.. code-block:: llvm - - 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>; - -Looping -^^^^^^^ - -TableGen supports the '``foreach``' block, which textually replicates the loop -body, substituting iterator values for iterator references in the body. -Example: - -.. code-block:: llvm - - foreach i = [0, 1, 2, 3] in { - def R#i : Register<...>; - def F#i : Register<...>; - } - -This will create objects ``R0``, ``R1``, ``R2`` and ``R3``. ``foreach`` blocks -may be nested. If there is only one item in the body the braces may be -elided: - -.. code-block:: llvm - - foreach i = [0, 1, 2, 3] in - def R#i : Register<...>; - -Code Generator backend info -=========================== - -Expressions used by code generator to describe instructions and isel patterns: - -``(implicit a)`` - an implicitly defined physical register. This tells the dag instruction - selection emitter the input pattern's extra definitions matches implicit - physical register definitions. - -.. _TableGen backend: -.. _TableGen backends: -.. _write a backend: - -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``. +The TableGen fundamentals documentation has moved to a directory on its own +and is now available at :doc:`TableGen/index`. Please, change your links to +that page. |