docs/TableGenFundamentals.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   2                       "http://www.w3.org/TR/html4/strict.dtd">
   3 <html>
   4 <head>
   5   <title>TableGen Fundamentals</title>
   6   <link rel="stylesheet" href="llvm.css" type="text/css">
   7 </head>
   8 <body>
   9
  10 <div class="doc_title">TableGen Fundamentals</div>
  11
  12 <div class="doc_text">
  13 <ul>
  14   <li><a href="#introduction">Introduction</a>
  15   <ol>
  16     <li><a href="#concepts">Basic concepts</a></li>
  17     <li><a href="#example">An example record</a></li>
  18     <li><a href="#running">Running TableGen</a></li>
  19   </ol></li>
  20   <li><a href="#syntax">TableGen syntax</a>
  21   <ol>
  22     <li><a href="#primitives">TableGen primitives</a>
  23     <ol>
  24       <li><a href="#comments">TableGen comments</a></li>
  25       <li><a href="#types">The TableGen type system</a></li>
  26       <li><a href="#values">TableGen values and expressions</a></li>
  27     </ol></li>
  28     <li><a href="#classesdefs">Classes and definitions</a>
  29     <ol>
  30       <li><a href="#valuedef">Value definitions</a></li>
  31       <li><a href="#recordlet">'let' expressions</a></li>
  32       <li><a href="#templateargs">Class template arguments</a></li>
  33     </ol></li>
  34     <li><a href="#filescope">File scope entities</a>
  35     <ol>
  36       <li><a href="#include">File inclusion</a></li>
  37       <li><a href="#globallet">'let' expressions</a></li>
  38     </ol></li>
  39   </ol></li>
  40   <li><a href="#backends">TableGen backends</a>
  41   <ol>
  42     <li><a href="#">todo</a></li>
  43   </ol></li>
  44   <li><a href="#codegenerator">The LLVM code generator</a>
  45   <ol>
  46     <li><a href="#">todo</a></li>
  47   </ol></li>
  48 </ul>
  49 </div>
  50
  51 <!-- *********************************************************************** -->
  52 <div class="doc_section"><a name="introduction">Introduction</a></div>
  53 <!-- *********************************************************************** -->
  54
  55 <div class="doc_text">
  56
  57 <p>TableGen's purpose is to help a human develop and maintain records of
  58 domain-specific information.  Because there may be a large number of these
  59 records, it is specifically designed to allow writing flexible descriptions and
  60 for common features of these records to be factored out.  This reduces the
  61 amount of duplication in the description, reduces the chance of error, and
  62 makes it easier to structure domain specific information.</p>
  63
  64 <p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
  65 the declarations, and hands the result off to a domain-specific "<a
  66 href="#backends">TableGen backend</a>" for processing.  The current major user
  67 of TableGen is the <a href="#codegenerator">LLVM code generator</a>.</p>
  68
  69 <p>Note that if you work on TableGen much, and use emacs or vim, that you can
  70 find an emacs "TableGen mode" and a vim language file in
  71 <tt>llvm/utils/emacs</tt> and <tt>llvm/utils/vim</tt> directory of your LLVM
  72 distribution, respectively.</p>
  73
  74 </div>
  75
  76 <!-- ======================================================================= -->
  77 <div class="doc_subsection"><a name="running">Basic concepts</a></div>
  78
  79 <div class="doc_text">
  80
  81 <p>TableGen files consist of two key parts: 'classes' and 'definitions', both
  82 of which are considered 'records'.</p>
  83
  84 <p><b>TableGen records</b> have a unique name, a list of values, and a list of
  85 superclasses.  The list of values is main data that TableGen builds for each
  86 record, it is this that holds the domain specific information for the
  87 application.  The interpretation of this data is left to a specific <a
  88 href="#backends">TableGen backend</a>, but the structure and format rules are
  89 taken care of and fixed by TableGen.</p>
  90
  91 <p><b>TableGen definitions</b> are the concrete form of 'records'.  These
  92 generally do not have any undefined values, and are marked with the
  93 '<tt>def</tt>' keyword.</p>
  94
  95 <p><b>TableGen classes</b> are abstract records that are used to build and
  96 describe other records.  These 'classes' allow the end-user to build
  97 abstractions for either the domain they are targetting (such as "Register",
  98 "RegisterClass", and "Instruction" in the LLVM code generator) or for the
  99 implementor to help factor out common properties of records (such as "FPInst",
 100 which is used to represent floating point instructions in the X86 backend).
 101 TableGen keeps track of all of the classes that are used to build up a
 102 definition, so the backend can find all definitions of a particular class, such
 103 as "Instruction".</p>
 104
 105 </div>
 106
 107 <!-- ======================================================================= -->
 108 <div class="doc_subsection"><a name="example">An example record</a></div>
 109
 110 <div class="doc_text">
 111
 112 <p>With no other arguments, TableGen parses the specified file and prints out
 113 all of the classes, then all of the definitions.  This is a good way to see what
 114 the various definitions expand to fully.  Running this on the <tt>X86.td</tt>
 115 file prints this (at the time of this writing):</p>
 116
 117 <pre>
 118 ...
 119 <b>def</b> ADDrr8 {    <i>// Instruction X86Inst I2A8 Pattern</i>
 120   <b>string</b> Name = "add";
 121   <b>string</b> Namespace = "X86";
 122   <b>list</b>&lt;Register&gt; Uses = [];
 123   <b>list</b>&lt;Register&gt; Defs = [];
 124   <b>bit</b> isReturn = 0;
 125   <b>bit</b> isBranch = 0;
 126   <b>bit</b> isCall = 0;
 127   <b>bit</b> isTwoAddress = 1;
 128   <b>bit</b> isTerminator = 0;
 129   <b>dag</b> Pattern = (set R8, (plus R8, R8));
 130   <b>bits</b>&lt;8&gt; Opcode = { 0, 0, 0, 0, 0, 0, 0, 0 };
 131   Format Form = MRMDestReg;
 132   <b>bits</b>&lt;5&gt; FormBits = { 0, 0, 0, 1, 1 };
 133   ArgType Type = Arg8;
 134   <b>bits</b>&lt;3&gt; TypeBits = { 0, 0, 1 };
 135   <b>bit</b> hasOpSizePrefix = 0;
 136   <b>bit</b> printImplicitUses = 0;
 137   <b>bits</b>&lt;4&gt; Prefix = { 0, 0, 0, 0 };
 138   FPFormat FPForm = ?;
 139   <b>bits</b>&lt;3&gt; FPFormBits = { 0, 0, 0 };
 140 }
 141 ...
 142 </pre>
 143
 144 <p>This definition corresponds to an 8-bit register-register add instruction in
 145 the X86.  The string after the '<tt>def</tt>' string indicates the name of the
 146 record ("<tt>ADDrr8</tt>" in this case), and the comment at the end of the line
 147 indicates the superclasses of the definition.  The body of the record contains
 148 all of the data that TableGen assembled for the record, indicating that the
 149 instruction is part of the "X86" namespace, should be printed as "<tt>add</tt>"
 150 in the assembly file, it is a two-address instruction, has a particular
 151 encoding, etc.  The contents and semantics of the information in the record is
 152 specific to the needs of the X86 backend, and is only shown as an example.</p>
 153
 154 <p>As you can see, a lot of information is needed for every instruction
 155 supported by the code generator, and specifying it all manually would be
 156 unmaintainble, prone to bugs, and tiring to do in the first place.  Because we
 157 are using TableGen, all of the information was derived from the following
 158 definition:</p>
 159
 160 <pre>
 161 <b>def</b> ADDrr8   : I2A8&lt;"add", 0x00, MRMDestReg&gt;,
 162                Pattern&lt;(set R8, (plus R8, R8))&gt;;
 163 </pre>
 164
 165 <p>This definition makes use of the custom I2A8 (two address instruction with
 166 8-bit operand) class, which is defined in the X86-specific TableGen file to
 167 factor out the common features that instructions of its class share.  A key
 168 feature of TableGen is that it allows the end-user to define the abstractions
 169 they prefer to use when describing their information.</p>
 170
 171 </div>
 172
 173 <!-- ======================================================================= -->
 174 <div class="doc_subsection"><a name="running">Running TableGen</a></div>
 175
 176 <div class="doc_text">
 177
 178 <p>TableGen runs just like any other LLVM tool.  The first (optional) argument
 179 specifies the file to read.  If a filename is not specified, <tt>tblgen</tt>
 180 reads from standard input.</p>
 181
 182 <p>To be useful, one of the <a href="#backends">TableGen backends</a> must be
 183 used.  These backends are selectable on the command line (type '<tt>tblgen
 184 --help</tt>' for a list).  For example, to get a list of all of the definitions
 185 that subclass a particular type (which can be useful for building up an enum
 186 list of these records), use the <tt>--print-enums</tt> option:</p>
 187
 188 <pre>
 189 $ tblgen X86.td -print-enums -class=Register
 190 AH, AL, AX, BH, BL, BP, BX, CH, CL, CX, DH, DI, DL, DX,
 191 EAX, EBP, EBX, ECX, EDI, EDX, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6,
 192 SI, SP, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
 193
 194 $ tblgen X86.td -print-enums -class=Instruction
 195 ADCrr32, ADDri16, ADDri16b, ADDri32, ADDri32b, ADDri8, ADDrr16, ADDrr32,
 196 ADDrr8, ADJCALLSTACKDOWN, ADJCALLSTACKUP, ANDri16, ANDri16b, ANDri32, ANDri32b,
 197 ANDri8, ANDrr16, ANDrr32, ANDrr8, BSWAPr32, CALLm32, CALLpcrel32, ...
 198 </pre>
 199
 200 <p>The default backend prints out all of the records, as described <a
 201 href="#example">above</a>.</p>
 202
 203 <p>If you plan to use TableGen for some purpose, you will most likely have to
 204 <a href="#backends">write a backend</a> that extracts the information specific
 205 to what you need and formats it in the appropriate way.</p>
 206
 207 </div>
 208
 209
 210 <!-- *********************************************************************** -->
 211 <div class="doc_section"><a name="syntax">TableGen syntax</a></div>
 212 <!-- *********************************************************************** -->
 213
 214 <div class="doc_text">
 215 <p>TableGen doesn't care about the meaning of data (that is up to the backend
 216 to define), but it does care about syntax, and it enforces a simple type system.
 217 This section describes the syntax and the constructs allowed in a TableGen file.
 218 </p>
 219 </div>
 220
 221 <!-- ======================================================================= -->
 222 <div class="doc_subsection"><a name="primitives">TableGen primitives</a></div>
 223
 224 <!-- -------------------------------------------------------------------------->
 225 <div class="doc_subsubsection"><a name="comments">TableGen comments</a></div>
 226
 227 <div class="doc_text">
 228 <p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
 229 the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
 230 </div>
 231
 232 <!-- -------------------------------------------------------------------------->
 233 <div class="doc_subsubsection"><a name="types">The TableGen type system</a>
 234 </div>
 235
 236 <div class="doc_text">
 237 <p>TableGen files are strongly typed, in a simple (but complete) type-system.
 238 These types are used to perform automatic conversions, check for errors, and to
 239 help interface designers constrain the input that they allow.  Every <a
 240 href="#valuedef">value definition</a> is required to have an associated type.
 241 </p>
 242
 243 <p>TableGen supports a mixture of very low-level types (such as <tt>bit</tt>)
 244 and very high-level types (such as <tt>dag</tt>).  This flexibility is what
 245 allows it to describe a wide range of information conveniently and compactly.
 246 The TableGen types are:</p>
 247
 248 <ul>
 249 <li>"<tt><b>bit</b></tt>" - A 'bit' is a boolean value that can hold either 0 or
 250 1.</li>
 251
 252 <li>"<tt><b>int</b></tt>" - The 'int' type represents a simple 32-bit integer
 253 value, such as 5.</li>
 254
 255 <li>"<tt><b>string</b></tt>" - The 'string' type represents an ordered sequence
 256 of characters of arbitrary length.</li>
 257
 258 <li>"<tt><b>bits</b>&lt;n&gt;</tt>" - A 'bits' type is an arbitrary, but fixed,
 259 size integer that is broken up into individual bits.  This type is useful
 260 because it can handle some bits being defined while others are undefined.</li>
 261
 262 <li>"<tt><b>list</b>&lt;ty&gt;</tt>" - This type represents a list whose
 263 elements are some other type.  The contained type is arbitrary: it can even be
 264 another list type.</li>
 265
 266 <li>Class type - Specifying a class name in a type context means that the
 267 defined value must be a subclass of the specified class.  This is useful in
 268 conjunction with the "list" type, for example, to constrain the elements of the
 269 list to a common base class (e.g., a <tt><b>list</b>&lt;Register&gt;</tt> can
 270 only contain definitions derived from the "<tt>Register</tt>" class).</li>
 271
 272 <li>"<tt><b>code</b></tt>" - This represents a big hunk of text.  NOTE: I don't
 273 remember why this is distinct from string!</li>
 274
 275 <li>"<tt><b>dag</b></tt>" - This type represents a nestable directed graph of
 276 elements.</li>
 277 </ul>
 278
 279 <p>To date, these types have been sufficient for describing things that
 280 TableGen has been used for, but it is straight-forward to extend this list if
 281 needed.</p>
 282
 283 </div>
 284
 285 <!-- -------------------------------------------------------------------------->
 286 <div class="doc_subsubsection">
 287   <a name="values">TableGen values and expressions</a>
 288 </div>
 289
 290 <div>
 291 <p>TableGen allows for a pretty reasonable number of different expression forms
 292 when building up values.  These forms allow the TableGen file to be written in a
 293 natural syntax and flavor for the application.  The current expression forms
 294 supported include:</p>
 295
 296 <ul>
 297 <li>? - Uninitialized field.</li>
 298 <li>0b1001011 - Binary integer value.</li>
 299 <li>07654321 - Octal integer value (indicated by a leading 0).</li>
 300 <li>7 - Decimal integer value.</li>
 301 <li>0x7F - Hexadecimal integer value.</li>
 302 <li>"foo" - String value.</li>
 303 <li>[{ .... }] - Code fragment.</li>
 304 <li>[ X, Y, Z ] - List value.</li>
 305 <li>{ a, b, c } - Initializer for a "bits&lt;3&gt;" value.</li>
 306 <li>value - Value reference.</li>
 307 <li>value{17} - Access to one or more bits of a value.</li>
 308 <li>DEF - Reference to a record definition.</li>
 309 <li>X.Y - Reference to the subfield of a value.</li>
 310
 311 <li>(DEF a, b) - A dag value.  The first element is required to be a record
 312 definition, the remaining elements in the list may be arbitrary other values,
 313 including nested 'dag' values.</li>
 314
 315 </ul>
 316
 317 <p>Note that all of the values have rules specifying how they convert to values
 318 for different types.  These rules allow you to assign a value like "7" to a
 319 "bits&lt;4&gt;" value, for example.</p>
 320
 321 </div>
 322
 323 <!-- ======================================================================= -->
 324 <div class="doc_subsection"><a name="classesdefs">Classes and definitions</a>
 325 </div>
 326
 327 <div>
 328 <p>As mentioned in the <a href="#concepts">intro</a>, classes and definitions
 329 (collectively known as 'records') in TableGen are the main high-level unit of
 330 information that TableGen collects.  Records are defined with a <tt>def</tt> or
 331 <tt>class</tt> keyword, the record name, and an optional list of "<a
 332 href="templateargs">template arguments</a>".  If the record has superclasses,
 333 they are specified as a comma seperated list that starts with a colon character
 334 (":").  If <a href="#valuedef">value definitions</a> or <a href="#recordlet">let
 335 expressions</a> are needed for the class, they are enclosed in curly braces
 336 ("{}"); otherwise, the record ends with a semicolon.  Here is a simple TableGen
 337 file:</p>
 338
 339 <pre>
 340 <b>class</b> C { <b>bit</b> V = 1; }
 341 <b>def</b> X : C;
 342 <b>def</b> Y : C {
 343   <b>string</b> Greeting = "hello";
 344 }
 345 </pre>
 346
 347 <p>This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of
 348 which derive from the <tt>C</tt> class.  Because of this, they both get the
 349 <tt>V</tt> bit value.  The <tt>Y</tt> definition also gets the Greeting member
 350 as well.</p>
 351
 352 <p>In general, classes are useful for collecting together the commonality
 353 between a group of records and isolating it in a single place.  Also, classes
 354 permit the specification of default values for their subclasses, allowing the
 355 subclasses to override them as they wish.</p>
 356
 357 </div>
 358
 359 <!---------------------------------------------------------------------------->
 360 <div class="doc_subsubsection">
 361   <a name="valuedef">Value definitions</a>
 362 </div>
 363
 364 <div class="doc_text">
 365 <p>Value definitions define named entries in records.  A value must be defined
 366 before it can be referred to as the operand for another value definition or
 367 before the value is reset with a <a href="#recordlet">let expression</a>.  A
 368 value is defined by specifying a <a href="#types">TableGen type</a> and a name.
 369 If an initial value is available, it may be specified after the type with an
 370 equal sign.  Value definitions require terminating semicolons.</p>
 371 </div>
 372
 373 <!-- -------------------------------------------------------------------------->
 374 <div class="doc_subsubsection">
 375   <a name="recordlet">'let' expressions</a>
 376 </div>
 377
 378 <div class="doc_text">
 379 <p>A record-level let expression is used to change the value of a value
 380 definition in a record.  This is primarily useful when a superclass defines a
 381 value that a derived class or definition wants to override.  Let expressions
 382 consist of the '<tt>let</tt>' keyword followed by a value name, an equal sign
 383 ("="), and a new value.  For example, a new class could be added to the example
 384 above, redefining the <tt>V</tt> field for all of its subclasses:</p>
 385
 386 <pre>
 387 <b>class</b> D : C { let V = 0; }
 388 <b>def</b> Z : D;
 389 </pre>
 390
 391 <p>In this case, the <tt>Z</tt> definition will have a zero value for its "V"
 392 value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
 393 because the <tt>D</tt> class overrode its value.</p>
 394
 395 </div>
 396
 397 <!-- -------------------------------------------------------------------------->
 398 <div class="doc_subsubsection">
 399   <a name="templateargs">Class template arguments</a>
 400 </div>
 401
 402 <div class="doc_text">
 403 <p>TableGen permits the definition of parameterized classes as well as normal
 404 concrete classes.  Parameterized TableGen classes specify a list of variable
 405 bindings (which may optionally have defaults) that are bound when used.  Here is
 406 a simple example:</p>
 407
 408 <pre>
 409 <b>class</b> FPFormat&lt;<b>bits</b>&lt;3&gt; val&gt; {
 410   <b>bits</b>&lt;3&gt; Value = val;
 411 }
 412 <b>def</b> NotFP      : FPFormat&lt;0&gt;;
 413 <b>def</b> ZeroArgFP  : FPFormat&lt;1&gt;;
 414 <b>def</b> OneArgFP   : FPFormat&lt;2&gt;;
 415 <b>def</b> OneArgFPRW : FPFormat&lt;3&gt;;
 416 <b>def</b> TwoArgFP   : FPFormat&lt;4&gt;;
 417 <b>def</b> SpecialFP  : FPFormat&lt;5&gt;;
 418 </pre>
 419
 420 <p>In this case, template arguments are used as a space efficient way to specify
 421 a list of "enumeration values", each with a "Value" field set to the specified
 422 integer.</p>
 423
 424 <p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
 425 useful in conjunction with template arguments.  As an example:</p>
 426
 427 <pre>
 428 <b>class</b> ModRefVal&lt;<b>bits</b>&lt;2&gt; val&gt; {
 429   <b>bits</b>&lt;2&gt; Value = val;
 430 }
 431
 432 <b>def</b> None   : ModRefVal&lt;0&gt;;
 433 <b>def</b> Mod    : ModRefVal&lt;1&gt;;
 434 <b>def</b> Ref    : ModRefVal&lt;2&gt;;
 435 <b>def</b> ModRef : ModRefVal&lt;3&gt;;
 436
 437 <b>class</b> Value&lt;ModRefVal MR&gt; {
 438   <i>// decode some information into a more convenient format, while providing
 439   // a nice interface to the user of the "Value" class.</i>
 440   <b>bit</b> isMod = MR.Value{0};
 441   <b>bit</b> isRef = MR.Value{1};
 442
 443   <i>// other stuff...</i>
 444 }
 445
 446 <i>// Example uses</i>
 447 <b>def</b> bork : Value&lt;Mod&gt;;
 448 <b>def</b> zork : Value&lt;Ref&gt;;
 449 <b>def</b> hork : Value&lt;ModRef&gt;;
 450 </pre>
 451
 452 <p>This is obviously a contrived example, but it shows how template arguments
 453 can be used to decouple the interface provided to the user of the class from the
 454 actual internal data representation expected by the class.  In this case,
 455 running <tt>tblgen</tt> on the example prints the following definitions:</p>
 456
 457 <pre>
 458 <b>def</b> bork {      <i>// Value</i>
 459   bit isMod = 1;
 460   bit isRef = 0;
 461 }
 462 <b>def</b> hork {      <i>// Value</i>
 463   bit isMod = 1;
 464   bit isRef = 1;
 465 }
 466 <b>def</b> zork {      <i>// Value</i>
 467   bit isMod = 0;
 468   bit isRef = 1;
 469 }
 470 </pre>
 471
 472 <p> This shows that TableGen was able to dig into the argument and extract a
 473 piece of information that was requested by the designer of the "Value" class.
 474 For more realistic examples, please see existing users of TableGen, such as the
 475 X86 backend.</p>
 476
 477 </div>
 478
 479 <!-- ======================================================================= -->
 480 <div class="doc_subsection">
 481   <a name="filescope">File scope entities</a>
 482 </div>
 483
 484 <!-- -------------------------------------------------------------------------->
 485 <div class="doc_subsubsection">
 486   <a name="include">File inclusion</a>
 487 </div>
 488
 489 <div class="doc_text">
 490 <p>TableGen supports the '<tt>include</tt>' token, which textually substitutes
 491 the specified file in place of the include directive.  The filename should be
 492 specified as a double quoted string immediately after the '<tt>include</tt>'
 493 keyword.  Example:</p>
 494
 495 <pre>
 496 <b>include</b> "foo.td"
 497 </pre>
 498
 499 </div>
 500
 501 <!-- -------------------------------------------------------------------------->
 502 <div class="doc_subsubsection">
 503   <a name="globallet">'let' expressions</a>
 504 </div>
 505
 506 <div class="doc_text">
 507 <p> "let" expressions at file scope are similar to <a href="#recordlet">"let"
 508 expressions within a record</a>, except they can specify a value binding for
 509 multiple records at a time, and may be useful in certain other cases.
 510 File-scope let expressions are really just another way that TableGen allows the
 511 end-user to factor out commonality from the records.</p>
 512
 513 <p>File-scope "let" expressions take a comma-seperated list of bindings to
 514 apply, and one of more records to bind the values in.  Here are some
 515 examples:</p>
 516
 517 <pre>
 518 <b>let</b> isTerminator = 1, isReturn = 1 <b>in</b>
 519   <b>def</b> RET : X86Inst&lt;"ret", 0xC3, RawFrm, NoArg&gt;;
 520
 521 <b>let</b> isCall = 1 <b>in</b>
 522   <i>// All calls clobber the non-callee saved registers...</i>
 523   <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6] in {
 524     <b>def</b> CALLpcrel32 : X86Inst&lt;"call", 0xE8, RawFrm, NoArg&gt;;
 525     <b>def</b> CALLr32     : X86Inst&lt;"call", 0xFF, MRMS2r, Arg32&gt;;
 526     <b>def</b> CALLm32     : X86Inst&lt;"call", 0xFF, MRMS2m, Arg32&gt;;
 527   }
 528 </pre>
 529
 530 <p>File-scope "let" expressions are often useful when a couple of definitions
 531 need to be added to several records, and the records do not otherwise need to be
 532 opened, as in the case with the CALL* instructions above.</p>
 533 </div>
 534
 535 <!-- *********************************************************************** -->
 536 <div class="doc_section"><a name="backends">TableGen backends</a></div>
 537 <!-- *********************************************************************** -->
 538
 539 <div class="doc_text">
 540 <p>How they work, how to write one.  This section should not contain details
 541 about any particular backend, except maybe -print-enums as an example.  This
 542 should highlight the APIs in <tt>TableGen/Record.h</tt>.</p>
 543 </div>
 544
 545 <!-- *********************************************************************** -->
 546 <div class="doc_section"><a name="codegenerator">The LLVM code generator</a>
 547 </div>
 548 <!-- *********************************************************************** -->
 549
 550 <div class="doc_text">
 551 <p>This is just a temporary, convenient, place to put stuff about the code
 552 generator before it gets its own document.  This should describe all of the
 553 tablegen backends used by the code generator and the classes/definitions they
 554 expect.</p>
 555 </div>
 556
 557 <!-- *********************************************************************** -->
 558
 559 <hr>
 560 <address>
 561   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
 562   src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
 563   <a href="http://validator.w3.org/check/referer"><img
 564   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
 565
 566   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
 567   <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
 568   Last modified: $Date$
 569 </address>
 570
 571 </body>
 572 </html>