Recommit r373598 "[yaml2obj/obj2yaml] - Add support for SHT_LLVM_ADDRSIG sections."
[llvm-complete.git] / docs / TableGen / LangIntro.rst
blob45104ac78b8ab285156a17fce15f49029d1ba0eb
1 ==============================
2 TableGen Language Introduction
3 ==============================
5 .. contents::
6    :local:
8 .. warning::
9    This document is extremely rough. If you find something lacking, please
10    fix it, file a documentation bug, or ask about it on llvm-dev.
12 Introduction
13 ============
15 This document is not meant to be a normative spec about the TableGen language
16 in and of itself (i.e. how to understand a given construct in terms of how
17 it affects the final set of records represented by the TableGen file). For
18 the formal language specification, see :doc:`LangRef`.
20 TableGen syntax
21 ===============
23 TableGen doesn't care about the meaning of data (that is up to the backend to
24 define), but it does care about syntax, and it enforces a simple type system.
25 This section describes the syntax and the constructs allowed in a TableGen file.
27 TableGen primitives
28 -------------------
30 TableGen comments
31 ^^^^^^^^^^^^^^^^^
33 TableGen supports C++ style "``//``" comments, which run to the end of the
34 line, and it also supports **nestable** "``/* */``" comments.
36 .. _TableGen type:
38 The TableGen type system
39 ^^^^^^^^^^^^^^^^^^^^^^^^
41 TableGen files are strongly typed, in a simple (but complete) type-system.
42 These types are used to perform automatic conversions, check for errors, and to
43 help interface designers constrain the input that they allow.  Every `value
44 definition`_ is required to have an associated type.
46 TableGen supports a mixture of very low-level types (such as ``bit``) and very
47 high-level types (such as ``dag``).  This flexibility is what allows it to
48 describe a wide range of information conveniently and compactly.  The TableGen
49 types are:
51 ``bit``
52     A 'bit' is a boolean value that can hold either 0 or 1.
54 ``int``
55     The 'int' type represents a simple 32-bit integer value, such as 5.
57 ``string``
58     The 'string' type represents an ordered sequence of characters of arbitrary
59     length.
61 ``code``
62     The `code` type represents a code fragment, which can be single/multi-line
63     string literal.
65 ``bits<n>``
66     A 'bits' type is an arbitrary, but fixed, size integer that is broken up
67     into individual bits.  This type is useful because it can handle some bits
68     being defined while others are undefined.
70 ``list<ty>``
71     This type represents a list whose elements are some other type.  The
72     contained type is arbitrary: it can even be another list type.
74 Class type
75     Specifying a class name in a type context means that the defined value must
76     be a subclass of the specified class.  This is useful in conjunction with
77     the ``list`` type, for example, to constrain the elements of the list to a
78     common base class (e.g., a ``list<Register>`` can only contain definitions
79     derived from the "``Register``" class).
81 ``dag``
82     This type represents a nestable directed graph of elements.
84 To date, these types have been sufficient for describing things that TableGen
85 has been used for, but it is straight-forward to extend this list if needed.
87 .. _TableGen expressions:
89 TableGen values and expressions
90 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
92 TableGen allows for a pretty reasonable number of different expression forms
93 when building up values.  These forms allow the TableGen file to be written in a
94 natural syntax and flavor for the application.  The current expression forms
95 supported include:
97 ``?``
98     uninitialized field
100 ``0b1001011``
101     binary integer value.
102     Note that this is sized by the number of bits given and will not be
103     silently extended/truncated.
105 ``7``
106     decimal integer value
108 ``0x7F``
109     hexadecimal integer value
111 ``"foo"``
112     a single-line string value, can be assigned to ``string`` or ``code`` variable.
114 ``[{ ... }]``
115     usually called a "code fragment", but is just a multiline string literal
117 ``[ X, Y, Z ]<type>``
118     list value.  <type> is the type of the list element and is usually optional.
119     In rare cases, TableGen is unable to deduce the element type in which case
120     the user must specify it explicitly.
122 ``{ a, b, 0b10 }``
123     initializer for a "bits<4>" value.
124     1-bit from "a", 1-bit from "b", 2-bits from 0b10.
126 ``value``
127     value reference
129 ``value{17}``
130     access to one bit of a value
132 ``value{15-17}``
133     access to an ordered sequence of bits of a value, in particular ``value{15-17}``
134     produces an order that is the reverse of ``value{17-15}``.
136 ``DEF``
137     reference to a record definition
139 ``CLASS<val list>``
140     reference to a new anonymous definition of CLASS with the specified template
141     arguments.
143 ``X.Y``
144     reference to the subfield of a value
146 ``list[4-7,17,2-3]``
147     A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from it.
148     Elements may be included multiple times.
150 ``foreach <var> = [ <list> ] in { <body> }``
152 ``foreach <var> = [ <list> ] in <def>``
153     Replicate <body> or <def>, replacing instances of <var> with each value
154     in <list>.  <var> is scoped at the level of the ``foreach`` loop and must
155     not conflict with any other object introduced in <body> or <def>.  Only
156     ``def``\s and ``defm``\s are expanded within <body>.
158 ``foreach <var> = 0-15 in ...``
160 ``foreach <var> = {0-15,32-47} in ...``
161     Loop over ranges of integers. The braces are required for multiple ranges.
163 ``(DEF a, b)``
164     a dag value.  The first element is required to be a record definition, the
165     remaining elements in the list may be arbitrary other values, including
166     nested ```dag``' values.
168 ``!con(a, b, ...)``
169     Concatenate two or more DAG nodes. Their operations must equal.
171     Example: !con((op a1:$name1, a2:$name2), (op b1:$name3)) results in
172     the DAG node (op a1:$name1, a2:$name2, b1:$name3).
174 ``!dag(op, children, names)``
175     Generate a DAG node programmatically. 'children' and 'names' must be lists
176     of equal length or unset ('?'). 'names' must be a 'list<string>'.
178     Due to limitations of the type system, 'children' must be a list of items
179     of a common type. In practice, this means that they should either have the
180     same type or be records with a common superclass. Mixing dag and non-dag
181     items is not possible. However, '?' can be used.
183     Example: !dag(op, [a1, a2, ?], ["name1", "name2", "name3"]) results in
184     (op a1:$name1, a2:$name2, ?:$name3).
186 ``!listconcat(a, b, ...)``
187     A list value that is the result of concatenating the 'a' and 'b' lists.
188     The lists must have the same element type.
189     More than two arguments are accepted with the result being the concatenation
190     of all the lists given.
192 ``!listsplat(a, size)``
193     A list value that contains the value ``a`` ``size`` times.
194     Example: ``!listsplat(0, 2)`` results in ``[0, 0]``.
196 ``!strconcat(a, b, ...)``
197     A string value that is the result of concatenating the 'a' and 'b' strings.
198     More than two arguments are accepted with the result being the concatenation
199     of all the strings given.
201 ``str1#str2``
202     "#" (paste) is a shorthand for !strconcat.  It may concatenate things that
203     are not quoted strings, in which case an implicit !cast<string> is done on
204     the operand of the paste.
206 ``!cast<type>(a)``
207     If 'a' is a string, a record of type *type* obtained by looking up the
208     string 'a' in the list of all records defined by the time that all template
209     arguments in 'a' are fully resolved.
211     For example, if !cast<type>(a) appears in a multiclass definition, or in a
212     class instantiated inside of a multiclass definition, and 'a' does not
213     reference any template arguments of the multiclass, then a record of name
214     'a' must be instantiated earlier in the source file. If 'a' does reference
215     a template argument, then the lookup is delayed until defm statements
216     instantiating the multiclass (or later, if the defm occurs in another
217     multiclass and template arguments of the inner multiclass that are
218     referenced by 'a' are substituted by values that themselves contain
219     references to template arguments of the outer multiclass).
221     If the type of 'a' does not match *type*, TableGen aborts with an error.
223     Otherwise, perform a normal type cast e.g. between an int and a bit, or
224     between record types. This allows casting a record to a subclass, though if
225     the types do not match, constant folding will be inhibited. !cast<string>
226     is a special case in that the argument can be an int or a record. In the
227     latter case, the record's name is returned.
229 ``!isa<type>(a)``
230     Returns an integer: 1 if 'a' is dynamically of the given type, 0 otherwise.
232 ``!subst(a, b, c)``
233     If 'a' and 'b' are of string type or are symbol references, substitute 'b'
234     for 'a' in 'c.'  This operation is analogous to $(subst) in GNU make.
236 ``!foreach(a, b, c)``
237     For each member of dag or list 'b' apply operator 'c'. 'a' is the name
238     of a variable that will be substituted by members of 'b' in 'c'.
239     This operation is analogous to $(foreach) in GNU make.
241 ``!foldl(start, lst, a, b, expr)``
242     Perform a left-fold over 'lst' with the given starting value. 'a' and 'b'
243     are variable names which will be substituted in 'expr'. If you think of
244     expr as a function f(a,b), the fold will compute
245     'f(...f(f(start, lst[0]), lst[1]), ...), lst[n-1])' for a list of length n.
246     As usual, 'a' will be of the type of 'start', and 'b' will be of the type
247     of elements of 'lst'. These types need not be the same, but 'expr' must be
248     of the same type as 'start'.
250 ``!head(a)``
251     The first element of list 'a.'
253 ``!tail(a)``
254     The 2nd-N elements of list 'a.'
256 ``!empty(a)``
257     An integer {0,1} indicating whether list 'a' is empty.
259 ``!size(a)``
260     An integer indicating the number of elements in list 'a'.
262 ``!if(a,b,c)``
263   'b' if the result of 'int' or 'bit' operator 'a' is nonzero, 'c' otherwise.
265 ``!cond(condition_1 : val1, condition_2 : val2, ..., condition_n : valn)``
266     Instead of embedding !if inside !if which can get cumbersome,
267     one can use !cond. !cond returns 'val1' if the result of 'int' or 'bit'
268     operator 'condition1' is nonzero. Otherwise, it checks 'condition2'.
269     If 'condition2' is nonzero, returns 'val2', and so on.
270     If all conditions are zero, it reports an error.  
272     For example, to convert an integer 'x' into a string:
273       !cond(!lt(x,0) : "negative", !eq(x,0) : "zero", 1 : "positive")
275 ``!eq(a,b)``
276     'bit 1' if string a is equal to string b, 0 otherwise.  This only operates
277     on string, int and bit objects.  Use !cast<string> to compare other types of
278     objects.
280 ``!ne(a,b)``
281     The negation of ``!eq(a,b)``.
283 ``!le(a,b), !lt(a,b), !ge(a,b), !gt(a,b)``
284     (Signed) comparison of integer values that returns bit 1 or 0 depending on
285     the result of the comparison.
287 ``!shl(a,b)`` ``!srl(a,b)`` ``!sra(a,b)``
288     The usual shift operators. Operations are on 64-bit integers, the result
289     is undefined for shift counts outside [0, 63].
291 ``!add(a,b,...)`` ``!mul(a,b,...)`` ``!and(a,b,...)`` ``!or(a,b,...)``
292     The usual arithmetic and binary operators.
294 Note that all of the values have rules specifying how they convert to values
295 for different types.  These rules allow you to assign a value like "``7``"
296 to a "``bits<4>``" value, for example.
298 Classes and definitions
299 -----------------------
301 As mentioned in the :doc:`introduction <index>`, classes and definitions (collectively known as
302 'records') in TableGen are the main high-level unit of information that TableGen
303 collects.  Records are defined with a ``def`` or ``class`` keyword, the record
304 name, and an optional list of "`template arguments`_".  If the record has
305 superclasses, they are specified as a comma separated list that starts with a
306 colon character ("``:``").  If `value definitions`_ or `let expressions`_ are
307 needed for the class, they are enclosed in curly braces ("``{}``"); otherwise,
308 the record ends with a semicolon.
310 Here is a simple TableGen file:
312 .. code-block:: text
314   class C { bit V = 1; }
315   def X : C;
316   def Y : C {
317     string Greeting = "hello";
318   }
320 This example defines two definitions, ``X`` and ``Y``, both of which derive from
321 the ``C`` class.  Because of this, they both get the ``V`` bit value.  The ``Y``
322 definition also gets the Greeting member as well.
324 In general, classes are useful for collecting together the commonality between a
325 group of records and isolating it in a single place.  Also, classes permit the
326 specification of default values for their subclasses, allowing the subclasses to
327 override them as they wish.
329 .. _value definition:
330 .. _value definitions:
332 Value definitions
333 ^^^^^^^^^^^^^^^^^
335 Value definitions define named entries in records.  A value must be defined
336 before it can be referred to as the operand for another value definition or
337 before the value is reset with a `let expression`_.  A value is defined by
338 specifying a `TableGen type`_ and a name.  If an initial value is available, it
339 may be specified after the type with an equal sign.  Value definitions require
340 terminating semicolons.
342 .. _let expression:
343 .. _let expressions:
344 .. _"let" expressions within a record:
346 'let' expressions
347 ^^^^^^^^^^^^^^^^^
349 A record-level let expression is used to change the value of a value definition
350 in a record.  This is primarily useful when a superclass defines a value that a
351 derived class or definition wants to override.  Let expressions consist of the
352 '``let``' keyword followed by a value name, an equal sign ("``=``"), and a new
353 value.  For example, a new class could be added to the example above, redefining
354 the ``V`` field for all of its subclasses:
356 .. code-block:: text
358   class D : C { let V = 0; }
359   def Z : D;
361 In this case, the ``Z`` definition will have a zero value for its ``V`` value,
362 despite the fact that it derives (indirectly) from the ``C`` class, because the
363 ``D`` class overrode its value.
365 References between variables in a record are substituted late, which gives
366 ``let`` expressions unusual power. Consider this admittedly silly example:
368 .. code-block:: text
370   class A<int x> {
371     int Y = x;
372     int Yplus1 = !add(Y, 1);
373     int xplus1 = !add(x, 1);
374   }
375   def Z : A<5> {
376     let Y = 10;
377   }
379 The value of ``Z.xplus1`` will be 6, but the value of ``Z.Yplus1`` is 11. Use
380 this power wisely.
382 .. _template arguments:
384 Class template arguments
385 ^^^^^^^^^^^^^^^^^^^^^^^^
387 TableGen permits the definition of parameterized classes as well as normal
388 concrete classes.  Parameterized TableGen classes specify a list of variable
389 bindings (which may optionally have defaults) that are bound when used.  Here is
390 a simple example:
392 .. code-block:: text
394   class FPFormat<bits<3> val> {
395     bits<3> Value = val;
396   }
397   def NotFP      : FPFormat<0>;
398   def ZeroArgFP  : FPFormat<1>;
399   def OneArgFP   : FPFormat<2>;
400   def OneArgFPRW : FPFormat<3>;
401   def TwoArgFP   : FPFormat<4>;
402   def CompareFP  : FPFormat<5>;
403   def CondMovFP  : FPFormat<6>;
404   def SpecialFP  : FPFormat<7>;
406 In this case, template arguments are used as a space efficient way to specify a
407 list of "enumeration values", each with a "``Value``" field set to the specified
408 integer.
410 The more esoteric forms of `TableGen expressions`_ are useful in conjunction
411 with template arguments.  As an example:
413 .. code-block:: text
415   class ModRefVal<bits<2> val> {
416     bits<2> Value = val;
417   }
419   def None   : ModRefVal<0>;
420   def Mod    : ModRefVal<1>;
421   def Ref    : ModRefVal<2>;
422   def ModRef : ModRefVal<3>;
424   class Value<ModRefVal MR> {
425     // Decode some information into a more convenient format, while providing
426     // a nice interface to the user of the "Value" class.
427     bit isMod = MR.Value{0};
428     bit isRef = MR.Value{1};
430     // other stuff...
431   }
433   // Example uses
434   def bork : Value<Mod>;
435   def zork : Value<Ref>;
436   def hork : Value<ModRef>;
438 This is obviously a contrived example, but it shows how template arguments can
439 be used to decouple the interface provided to the user of the class from the
440 actual internal data representation expected by the class.  In this case,
441 running ``llvm-tblgen`` on the example prints the following definitions:
443 .. code-block:: text
445   def bork {      // Value
446     bit isMod = 1;
447     bit isRef = 0;
448   }
449   def hork {      // Value
450     bit isMod = 1;
451     bit isRef = 1;
452   }
453   def zork {      // Value
454     bit isMod = 0;
455     bit isRef = 1;
456   }
458 This shows that TableGen was able to dig into the argument and extract a piece
459 of information that was requested by the designer of the "Value" class.  For
460 more realistic examples, please see existing users of TableGen, such as the X86
461 backend.
463 Multiclass definitions and instances
464 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
466 While classes with template arguments are a good way to factor commonality
467 between two instances of a definition, multiclasses allow a convenient notation
468 for defining multiple definitions at once (instances of implicitly constructed
469 classes).  For example, consider an 3-address instruction set whose instructions
470 come in two forms: "``reg = reg op reg``" and "``reg = reg op imm``"
471 (e.g. SPARC). In this case, you'd like to specify in one place that this
472 commonality exists, then in a separate place indicate what all the ops are.
474 Here is an example TableGen fragment that shows this idea:
476 .. code-block:: text
478   def ops;
479   def GPR;
480   def Imm;
481   class inst<int opc, string asmstr, dag operandlist>;
483   multiclass ri_inst<int opc, string asmstr> {
484     def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
485                    (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
486     def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
487                    (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
488   }
490   // Instantiations of the ri_inst multiclass.
491   defm ADD : ri_inst<0b111, "add">;
492   defm SUB : ri_inst<0b101, "sub">;
493   defm MUL : ri_inst<0b100, "mul">;
494   ...
496 The name of the resultant definitions has the multidef fragment names appended
497 to them, so this defines ``ADD_rr``, ``ADD_ri``, ``SUB_rr``, etc.  A defm may
498 inherit from multiple multiclasses, instantiating definitions from each
499 multiclass.  Using a multiclass this way is exactly equivalent to instantiating
500 the classes multiple times yourself, e.g. by writing:
502 .. code-block:: text
504   def ops;
505   def GPR;
506   def Imm;
507   class inst<int opc, string asmstr, dag operandlist>;
509   class rrinst<int opc, string asmstr>
510     : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
511            (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
513   class riinst<int opc, string asmstr>
514     : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
515            (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
517   // Instantiations of the ri_inst multiclass.
518   def ADD_rr : rrinst<0b111, "add">;
519   def ADD_ri : riinst<0b111, "add">;
520   def SUB_rr : rrinst<0b101, "sub">;
521   def SUB_ri : riinst<0b101, "sub">;
522   def MUL_rr : rrinst<0b100, "mul">;
523   def MUL_ri : riinst<0b100, "mul">;
524   ...
526 A ``defm`` can also be used inside a multiclass providing several levels of
527 multiclass instantiations.
529 .. code-block:: text
531   class Instruction<bits<4> opc, string Name> {
532     bits<4> opcode = opc;
533     string name = Name;
534   }
536   multiclass basic_r<bits<4> opc> {
537     def rr : Instruction<opc, "rr">;
538     def rm : Instruction<opc, "rm">;
539   }
541   multiclass basic_s<bits<4> opc> {
542     defm SS : basic_r<opc>;
543     defm SD : basic_r<opc>;
544     def X : Instruction<opc, "x">;
545   }
547   multiclass basic_p<bits<4> opc> {
548     defm PS : basic_r<opc>;
549     defm PD : basic_r<opc>;
550     def Y : Instruction<opc, "y">;
551   }
553   defm ADD : basic_s<0xf>, basic_p<0xf>;
554   ...
556   // Results
557   def ADDPDrm { ...
558   def ADDPDrr { ...
559   def ADDPSrm { ...
560   def ADDPSrr { ...
561   def ADDSDrm { ...
562   def ADDSDrr { ...
563   def ADDY { ...
564   def ADDX { ...
566 ``defm`` declarations can inherit from classes too, the rule to follow is that
567 the class list must start after the last multiclass, and there must be at least
568 one multiclass before them.
570 .. code-block:: text
572   class XD { bits<4> Prefix = 11; }
573   class XS { bits<4> Prefix = 12; }
575   class I<bits<4> op> {
576     bits<4> opcode = op;
577   }
579   multiclass R {
580     def rr : I<4>;
581     def rm : I<2>;
582   }
584   multiclass Y {
585     defm SS : R, XD;
586     defm SD : R, XS;
587   }
589   defm Instr : Y;
591   // Results
592   def InstrSDrm {
593     bits<4> opcode = { 0, 0, 1, 0 };
594     bits<4> Prefix = { 1, 1, 0, 0 };
595   }
596   ...
597   def InstrSSrr {
598     bits<4> opcode = { 0, 1, 0, 0 };
599     bits<4> Prefix = { 1, 0, 1, 1 };
600   }
602 File scope entities
603 -------------------
605 File inclusion
606 ^^^^^^^^^^^^^^
608 TableGen supports the '``include``' token, which textually substitutes the
609 specified file in place of the include directive.  The filename should be
610 specified as a double quoted string immediately after the '``include``' keyword.
611 Example:
613 .. code-block:: text
615   include "foo.td"
617 'let' expressions
618 ^^^^^^^^^^^^^^^^^
620 "Let" expressions at file scope are similar to `"let" expressions within a
621 record`_, except they can specify a value binding for multiple records at a
622 time, and may be useful in certain other cases.  File-scope let expressions are
623 really just another way that TableGen allows the end-user to factor out
624 commonality from the records.
626 File-scope "let" expressions take a comma-separated list of bindings to apply,
627 and one or more records to bind the values in.  Here are some examples:
629 .. code-block:: text
631   let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
632     def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
634   let isCall = 1 in
635     // All calls clobber the non-callee saved registers...
636     let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
637                 MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
638                 XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
639       def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
640                              "call\t${dst:call}", []>;
641       def CALL32r     : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
642                           "call\t{*}$dst", [(X86call GR32:$dst)]>;
643       def CALL32m     : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
644                           "call\t{*}$dst", []>;
645     }
647 File-scope "let" expressions are often useful when a couple of definitions need
648 to be added to several records, and the records do not otherwise need to be
649 opened, as in the case with the ``CALL*`` instructions above.
651 It's also possible to use "let" expressions inside multiclasses, providing more
652 ways to factor out commonality from the records, specially if using several
653 levels of multiclass instantiations. This also avoids the need of using "let"
654 expressions within subsequent records inside a multiclass.
656 .. code-block:: text
658   multiclass basic_r<bits<4> opc> {
659     let Predicates = [HasSSE2] in {
660       def rr : Instruction<opc, "rr">;
661       def rm : Instruction<opc, "rm">;
662     }
663     let Predicates = [HasSSE3] in
664       def rx : Instruction<opc, "rx">;
665   }
667   multiclass basic_ss<bits<4> opc> {
668     let IsDouble = 0 in
669       defm SS : basic_r<opc>;
671     let IsDouble = 1 in
672       defm SD : basic_r<opc>;
673   }
675   defm ADD : basic_ss<0xf>;
677 Looping
678 ^^^^^^^
680 TableGen supports the '``foreach``' block, which textually replicates the loop
681 body, substituting iterator values for iterator references in the body.
682 Example:
684 .. code-block:: text
686   foreach i = [0, 1, 2, 3] in {
687     def R#i : Register<...>;
688     def F#i : Register<...>;
689   }
691 This will create objects ``R0``, ``R1``, ``R2`` and ``R3``.  ``foreach`` blocks
692 may be nested. If there is only one item in the body the braces may be
693 elided:
695 .. code-block:: text
697   foreach i = [0, 1, 2, 3] in
698     def R#i : Register<...>;
700 Code Generator backend info
701 ===========================
703 Expressions used by code generator to describe instructions and isel patterns:
705 ``(implicit a)``
706     an implicitly defined physical register.  This tells the dag instruction
707     selection emitter the input pattern's extra definitions matches implicit
708     physical register definitions.