1=================================== 2TableGen Backend Developer's Guide 3=================================== 4 5.. sectnum:: 6 7.. contents:: 8 :local: 9 10Introduction 11============ 12 13The purpose of TableGen is to generate complex output files based on 14information from source files that are significantly easier to code than the 15output files would be, and also easier to maintain and modify over time. The 16information is coded in a declarative style involving classes and records, 17which are then processed by TableGen. The internalized records are passed on 18to various backends, which extract information from a subset of the records 19and generate an output file. These output files are typically ``.inc`` files 20for C++, but may be any type of file that the backend developer needs. 21 22This document is a guide to writing a backend for TableGen. It is not a 23complete reference manual, but rather a guide to using the facilities 24provided by TableGen for the backends. For a complete reference to the 25various data structures and functions involved, see the Doxygen 26documentation. 27 28This document assumes that you have read the :doc:`TableGen Programmer's 29Reference <./ProgRef>`, which provides a detailed reference for coding 30TableGen source files. This document and the relevant Doxygen pages will be 31improved over time. 32 33Data Structures 34=============== 35 36The following sections describe the data structures that contain the classes 37and records that are collected from the TableGen source files by the 38TableGen parser. Note that the term *class* refers to an abstract record 39class, while the term *record* refers to a concrete record. 40 41Unless otherwise noted, functions associated with classes are instance 42functions. 43 44``RecordKeeper`` 45---------------- 46 47An instance of the ``RecordKeeper`` class acts as the container for all the 48classes and records parsed and collected by TableGen. The ``RecordKeeper`` 49instance is passed to the backend when it is invoked by TableGen. This class 50is usually abbreviated ``RK``. 51 52There are two maps in the recordkeeper, one for classes and one for records 53(the latter often referred to as *defs*). Each map maps the class or record 54name to an instance of the ``Record`` class (see `Record`_), which contains 55all the information about that class or record. The ``RecordKeeper`` class 56defines a type that must be used to declare these maps if they are requested 57directly. 58 59.. code-block:: text 60 61 using RecordMap = std::map<std::string, std::unique_ptr<Record>, 62 std::less<>>; 63 64In addition to the two maps, the ``RecordKeeper`` instance contains: 65 66* A map that maps the names of global variables to their values. 67 Global variables are defined in TableGen files with outer 68 ``defvar`` statements. 69 70* A counter for naming anonymous records. 71 72The ``RecordKeeper`` class provides a few useful functions. 73 74* Functions to get the complete class and record maps. 75 76* Functions to get a subset of the records based on their parent classes. 77 78* Functions to get individual classes, records, and globals. 79 80A ``RecordKeeper`` instance can be printed to an output stream with the ``<<`` 81operator. 82 83``Record`` 84---------- 85 86Each class or record built by TableGen is represented by an instance of 87the ``Record`` class. The ``RecordKeeper`` instance contains one map for the 88classes and one for the records. The primary data members of a record are 89the record name, the vector of field names and their values, and the vector of 90superclasses of the record. 91 92The record name is stored as a pointer to an ``Init`` (see `Init`_), which 93is a class whose instances hold TableGen values (sometimes refered to as 94*initializers*). The field names and values are stored in a vector of 95``RecordVal`` instances (see `RecordVal`_), each of which contains both the 96field name and its value. The superclass vector contains a sequence of 97pairs, with each pair including the superclass record and its source 98file location. 99 100In addition to those members, a ``Record`` instance contains: 101 102* A vector of source file locations that includes the record definition 103 itself, plus the locations of any multiclasses involved in its definition. 104 105* For a class record, a vector of the class's template arguments. 106 107* An instance of ``DefInit`` (see `DefInit`_) corresponding to this record. 108 109* A unique record ID. 110 111* A boolean that specifies whether this is a class definition. 112 113* A boolean that specifies whether this is an anonymous record. 114 115The ``Record`` class provides many useful functions. 116 117* Functions to get the record name, fields, source file locations, 118 template arguments, and unique ID. 119 120* Functions to get all the record's superclasses or just its direct 121 superclasses. 122 123* Functions to get a particular field value by specifying its name in various 124 forms, and returning its value in various forms 125 (see `Getting Record Names and Fields`_). 126 127* Boolean functions to check the various attributes of the record. 128 129A ``Record`` instance can be printed to an output stream with the ``<<`` 130operator. 131 132 133``RecordVal`` 134------------- 135 136Each field of a record is stored in an instance of the ``RecordVal`` class. 137The ``Record`` instance includes a vector of these value instances. A 138``RecordVal`` instance contains the name of the field, stored in an ``Init`` 139instance. It also contains the value of the field, likewise stored in an 140``Init``. (A better name for this class might be ``RecordField``.) 141 142In addition to those primary members, the ``RecordVal`` has other data members. 143 144* The source file location of the field definition. 145 146* The type of the field, stored as an instance 147 of the ``RecTy`` class (see `RecTy`_). 148 149The ``RecordVal`` class provides some useful functions. 150 151* Functions to get the name of the field in various forms. 152 153* A function to get the type of the field. 154 155* A function to get the value of the field. 156 157* A function to get the source file location. 158 159Note that field values are more easily obtained directly from the ``Record`` 160instance (see `Record`_). 161 162A ``RecordVal`` instance can be printed to an output stream with the ``<<`` 163operator. 164 165``RecTy`` 166--------- 167 168The ``RecTy`` class is used to represent the types of field values. It is 169the base class for a series of subclasses, one for each of the 170available field types. The ``RecTy`` class has one data member that is an 171enumerated type specifying the specific type of field value. (A better 172name for this class might be ``FieldTy``.) 173 174The ``RecTy`` class provides a few useful functions. 175 176* A virtual function to get the type name as a string. 177 178* A virtual function to check whether all the values of this type can 179 be converted to another given type. 180 181* A virtual function to check whether this type is a subtype of 182 another given type. 183 184* A function to get the corresponding ``list`` 185 type for lists with elements of this type. For example, the function 186 returns the ``list<int>`` type when called with the ``int`` type. 187 188The subclasses that inherit from ``RecTy`` are 189``BitRecTy``, 190``BitsRecTy``, 191``CodeRecTy``, 192``DagRecTy``, 193``IntRecTy``, 194``ListRecTy``, 195``RecordRecTy``, and 196``StringRecTy``. 197Some of these classes have additional members that 198are described in the following subsections. 199 200*All* of the classes derived from ``RecTy`` provide the ``get()`` function. 201It returns an instance of ``Recty`` corresponding to the derived class. 202Some of the ``get()`` functions require an argument to 203specify which particular variant of the type is desired. These arguments are 204described in the following subsections. 205 206A ``RecTy`` instance can be printed to an output stream with the ``<<`` 207operator. 208 209.. warning:: 210 It is not specified whether there is a single ``RecTy`` instance of a 211 particular type or multiple instances. 212 213 214``BitsRecTy`` 215~~~~~~~~~~~~~ 216 217This class includes a data member with the size of the ``bits`` value and a 218function to get that size. 219 220The ``get()`` function takes the length of the sequence, *n*, and returns the 221``BitsRecTy`` type corresponding to ``bits<``\ *n*\ ``>``. 222 223``ListRecTy`` 224~~~~~~~~~~~~~ 225 226This class includes a data member that specifies the type of the list's 227elements and a function to get that type. 228 229The ``get()`` function takes the ``RecTy`` *type* of the list members and 230returns the ``ListRecTy`` type corresponding to ``list<``\ *type*\ ``>``. 231 232 233``RecordRecTy`` 234~~~~~~~~~~~~~~~ 235 236This class includes data members that contain the list of parent classes of 237this record. It also provides a function to obtain the array of classes and 238two functions to get the iterator ``begin()`` and ``end()`` values. The 239class defines a type for the return values of the latter two functions. 240 241.. code-block:: text 242 243 using const_record_iterator = Record * const *; 244 245The ``get()`` function takes an ``ArrayRef`` of pointers to the ``Record`` 246instances of the *direct* superclasses of the record and returns the ``RecordRecTy`` 247corresponding to the record inheriting from those superclasses. 248 249``Init`` 250-------- 251 252The ``Init`` class is used to represent TableGen values. The name derives 253from *initialization value*. This class should not be confused with the 254``RecordVal`` class, which represents record fields, both their names and 255values. The ``Init`` class is the base class for a series of 256subclasses, one for each of the available value types. 257 258The primary data member 259of ``Init`` is an enumerated type that represents the specific type of the 260value. 261 262The ``Init`` class provides a few useful functions. 263 264* A boolean virtual function to determine whether a value is completely 265 specified; that is, has no uninitialized subvalues. 266 267* Virtual functions to get the value as a string. 268 269* Virtual functions to cast the value to other types, implement the bit 270 range feature of TableGen, and implement the list slice feature. 271 272The subclasses that inherit directly from ``Init`` are 273``UnsetInit`` and ``TypedInit``. 274 275An ``Init`` instance can be printed to an output stream with the ``<<`` 276operator. 277 278.. warning:: 279 It is not specified whether two separate initialization values with 280 the same underlying type and value (e.g., two strings with the value 281 "Hello") are represented by two ``Init``\ s or share the same ``Init``. 282 283``UnsetInit`` 284~~~~~~~~~~~~~ 285 286This class, a subclass of ``Init``, represents the unset (uninitialized) 287value. The static function ``get()`` can be used to obtain the singleton 288``Init`` of this type. 289 290 291``TypedInit`` 292~~~~~~~~~~~~~ 293 294This class, a subclass of ``Init``, acts as the parent class of the classes 295that represent specific value types (except for the unset value). These 296classes include ``BitInit``, ``BitsInit``, ``CodeInit``, ``DagInit``, 297``DefInit``, ``IntInit``, ``ListInit``, and ``StringInit``. (There are 298additional derived types used by the TableGen parser.) 299 300This class includes a data member that specifies the ``RecTy`` type of the 301value. It provides a function to get that ``RecTy`` type. 302 303``BitInit`` 304~~~~~~~~~~~ 305 306The ``BitInit`` class is a subclass of ``TypedInit``. Its instances 307represent the possible values of a bit: 0 or 1. It includes a data member 308that contains the bit. 309 310*All* of the classes derived from ``TypedInit`` provide the following functions. 311 312* A static function named ``get()`` that returns an ``Init`` representing 313 the specified value(s). In the case of ``BitInit``, ``get(true)`` returns 314 an instance of ``BitInit`` representing true, while ``get(false)`` returns 315 an instance 316 representing false. As noted above, it is not specified whether there 317 is exactly one or more than one ``BitInit`` representing true (or false). 318 319* A function named ``GetValue()`` that returns the value of the instance 320 in a more direct form, in this case as a ``bool``. 321 322``BitsInit`` 323~~~~~~~~~~~~ 324 325The ``BitsInit`` class is a subclass of ``TypedInit``. Its instances 326represent sequences of bits, from high-order to low-order. It includes a 327data member with the length of the sequence and a vector of pointers to 328``Init`` instances, one per bit. 329 330The class provides the usual ``get()`` function. It does not provide the 331``getValue()`` function. 332 333The class provides the following additional functions. 334 335* A function to get the number of bits in the sequence. 336 337* A function that gets a bit specified by an integer index. 338 339``CodeInit`` 340~~~~~~~~~~~~ 341 342The ``CodeInit`` class is a subclass of ``TypedInit``. Its instances 343represent arbitrary-length strings produced from ``code`` literals in the 344TableGen files. It includes a data member that contains a ``StringRef`` of 345the value. It also includes a data member specifying the source code 346location of the code stirng. 347 348The class provides the usual ``get()`` and ``getValue()`` functions. The 349latter function returns the ``StringRef``. 350 351The ``getLoc()`` function returns the source code location. 352 353 354``DagInit`` 355~~~~~~~~~~~ 356 357The ``DagInit`` class is a subclass of ``TypedInit``. Its instances 358represent the possible direct acyclic graphs (``dag``). 359 360The class includes a pointer to an ``Init`` for the DAG operator and a 361pointer to a ``StringInit`` for the operator name. It includes the count of 362DAG operands and the count of operand names. Finally, it includes a vector of 363pointers to ``Init`` instances for the operands and another to 364``StringInit`` instances for the operand names. 365(The DAG operands are also referred to as *arguments*.) 366 367The class provides two forms of the usual ``get()`` function. It does not 368provide the usual ``getValue()`` function. 369 370The class provides many additional functions: 371 372* Functions to get the operator in various forms and to get the 373 operator name in various forms. 374 375* Functions to determine whether there are any operands and to get the 376 number of operands. 377 378* Functions to the get the operands, both individually and together. 379 380* Functions to determine whether there are any names and to 381 get the number of names 382 383* Functions to the get the names, both individually and together. 384 385* Functions to get the operand iterator ``begin()`` and ``end()`` values. 386 387* Functions to get the name iterator ``begin()`` and ``end()`` values. 388 389The class defines two types for the return values of the operand and name 390iterators. 391 392.. code-block:: text 393 394 using const_arg_iterator = SmallVectorImpl<Init*>::const_iterator; 395 using const_name_iterator = SmallVectorImpl<StringInit*>::const_iterator; 396 397 398``DefInit`` 399~~~~~~~~~~~ 400 401The ``DefInit`` class is a subclass of ``TypedInit``. Its instances 402represent the records that were collected by TableGen. It includes a data 403member that is a pointer to the record's ``Record`` instance. 404 405The class provides the usual ``get()`` function. It does not provide 406``getValue()``. Instead, it provides ``getDef()``, which returns the 407``Record`` instance. 408 409``IntInit`` 410~~~~~~~~~~~ 411 412The ``IntInit`` class is a subclass of ``TypedInit``. Its instances 413represent the possible values of a 64-bit integer. It includes a data member 414that contains the integer. 415 416The class provides the usual ``get()`` and ``getValue()`` functions. The 417latter function returns the integer as an ``int64_t``. 418 419The class also provides a function, ``getBit()``, to obtain a specified bit 420of the integer value. 421 422``ListInit`` 423~~~~~~~~~~~~ 424 425The ``ListInit`` class is a subclass of ``TypedInit``. Its instances 426represent lists of elements of some type. It includes a data member with the 427length of the list and a vector of pointers to ``Init`` instances, one per 428element. 429 430The class provides the usual ``get()`` and ``getValues()`` functions. The 431latter function returns an ``ArrayRef`` of the vector of pointers to ``Init`` 432instances. 433 434The class provides these additional functions. 435 436* A function to get the element type. 437 438* Functions to get the length of the vector and to determine whether 439 it is empty. 440 441* Functions to get an element specified by an integer index and return 442 it in various forms. 443 444* Functions to get the iterator ``begin()`` and ``end()`` values. The 445 class defines a type for the return type of these two functions. 446 447.. code-block:: text 448 449 using const_iterator = Init *const *; 450 451 452``StringInit`` 453~~~~~~~~~~~~~~ 454 455The ``StringInit`` class is a subclass of ``TypedInit``. Its instances 456represent arbitrary-length strings. It includes a data member 457that contains a ``StringRef`` of the value. 458 459The class provides the usual ``get()`` and ``getValue()`` functions. The 460latter function returns the ``StringRef``. 461 462Creating a New Backend 463====================== 464 465The following steps are required to create a new backend for TableGen. 466 467#. Invent a name for your backend C++ file, say ``GenAddressModes``. 468 469#. Write the new backend, using the file ``TableGenBackendSkeleton.cpp`` 470 as a starting point. 471 472#. Determine which instance of TableGen requires the new backend. There is 473 one instance for Clang and another for LLVM. Or you may be building 474 your own instance. 475 476#. Modify the selected ``tablegen.cpp`` to include your new backend. 477 478 a. Add the name to the enumerated type ``ActionType``. 479 480 #. Add a keyword to the ``ActionType`` command option using the 481 ``clEnumValN()`` function. 482 483 #. Add a case to the ``switch`` statement in the *xxx*\ ``TableGenMain()`` 484 function. It should invoke the "main function" of your backend, which 485 in this case, according to convention, is named ``EmitAddressModes``. 486 4875. Add a declaration of your "main function" to the corresponding 488 ``TableGenBackends.h`` header file. 489 490#. Add your backend C++ file to the appropriate ``CMakeLists.txt`` file so 491 that it will be built. 492 493#. Add your C++ file to the system. 494 495The Backend Skeleton 496==================== 497 498The file ``TableGenBackendSkeleton.cpp`` provides a skeleton C++ translation 499unit for writing a new TableGen backend. Here are a few notes on the file. 500 501* The list of includes is the minimal list required by most backends. 502 503* As with all LLVM C++ files, it has a ``using namespace llvm;`` statement. 504 It also has an anonymous namespace that contains all the file-specific 505 data structure definitions, along with the class embodying the emitter 506 data members and functions. Continuing with the ``GenAddressModes`` example, 507 this class is named ``AddressModesEmitter``. 508 509* The constructor for the emitter class accepts a ``RecordKeeper`` reference, 510 typically named ``RK``. The ``RecordKeeper`` reference is saved in a data 511 member so that records can be obtained from it. This data member is usually 512 named ``Records``. 513 514* One function is named ``run``. It is invoked by the backend's "main 515 function" to collect records and emit the output file. It accepts an instance 516 of the ``raw_ostream`` class, typically named ``OS``. The output file is 517 emitted by writing to this stream. 518 519* The ``run`` function should use the ``emitSourceFileHeader`` helper function 520 to include a standard header in the emitted file. 521 522* The only function in the ``llvm`` namespace is the backend "main function." 523 In this example, it is named ``EmitAddressModes``. It creates an instance 524 of the ``AddressModesEmitter`` class, passing the ``RecordKeeper`` 525 instance, then invokes the ``run`` function, passing the ``raw_ostream`` 526 instance. 527 528All the examples in the remainder of this document will assume the naming 529conventions used in the skeleton file. 530 531Getting Classes 532=============== 533 534The ``RecordKeeper`` class provides two functions for getting the 535``Record`` instances for classes defined in the TableGen files. 536 537* ``getClasses()`` returns a ``RecordMap`` reference for all the classes. 538 539* ``getClass(``\ *name*\ ``)`` returns a ``Record`` reference for the named 540 class. 541 542If you need to iterate over all the class records: 543 544.. code-block:: text 545 546 for (auto ClassPair : Records.getClasses()) { 547 Record *ClassRec = ClassPair.second.get(); 548 ... 549 } 550 551``ClassPair.second`` gets the class's ``unique_ptr``, then ``.get()`` gets the 552class ``Record`` itself. 553 554 555Getting Records 556=============== 557 558The ``RecordKeeper`` class provides four functions for getting the 559``Record`` instances for concrete records defined in the TableGen files. 560 561* ``getDefs()`` returns a ``RecordMap`` reference for all the concrete 562 records. 563 564* ``getDef(``\ *name*\ ``)`` return a ``Record`` reference for the named 565 concrete record. 566 567* ``getAllDerivedDefinitions(``\ *classname*\ ``)`` returns a vector of 568 ``Record`` references for the concrete records that derive from the 569 given class. 570 571* ``getAllDerivedDefinitionsTwo(``\ *classname1*\ ``,`` *classname2*\ ``)`` returns 572 a vector of ``Record`` references for the concrete records that derive from 573 *both* of the given classes. [function to come] 574 575This statement obtains all the records that derive from the ``Attribute`` 576class and iterates over them. 577 578.. code-block:: text 579 580 auto AttrRecords = Records.getAllDerivedDefinitions("Attribute"); 581 for (Record *AttrRec : AttrRecords) { 582 ... 583 } 584 585Getting Record Names and Fields 586=============================== 587 588As described above (see `Record`_), there are multiple functions that 589return the name of a record. One particularly useful one is 590``getNameInitAsString()``, which returns the name as a ``std::string``. 591 592There are also multiple functions that return the fields of a record. To 593obtain and iterate over all the fields: 594 595.. code-block:: text 596 597 for (const RecordVal &Field : SomeRec->getValues()) { 598 ... 599 } 600 601You will recall that ``RecordVal`` is the class whose instances contain 602information about the fields in records. 603 604The ``getValue()`` function returns the ``RecordVal`` instance for a field 605specified by name. There are multiple overloaded functions, some taking a 606``StringRef`` and others taking a ``const Init *``. Some functions return a 607``RecordVal *`` and others return a ``const RecordVal *``. If the field does 608not exist, a fatal error message is printed. 609 610More often than not, you are interested in the value of the field, not all 611the information in the ``RecordVal``. There is a large set of functions that 612take a field name in some form and return its value. One function, 613``getValueInit``, returns the value as an ``Init *``. Another function, 614``isValueUnset``, returns a boolean specifying whether the value is unset 615(uninitialized). 616 617Most of the functions return the value in some more useful form. For 618example: 619 620.. code-block:: text 621 622 std::vector<int64_t> RegCosts = 623 SomeRec->getValueAsListOfInts("RegCosts"); 624 625The field ``RegCosts`` is assumed to be a list of integers. That list is 626returned as a ``std::vector`` of 64-bit integers. If the field is not a list 627of integers, a fatal error message is printed. 628 629Here is a function that returns a field value as a ``Record``, but returns 630null if the field does not exist. 631 632.. code-block:: text 633 634 if (Record *BaseRec = SomeRec->getValueAsOptionalDef(BaseFieldName)) { 635 ... 636 } 637 638The field is assumed to have another record as its value. That record is returned 639as a pointer to a ``Record``. If the field does not exist or is unset, the 640functions returns null. 641 642Getting Record Superclasses 643=========================== 644 645The ``Record`` class provides a function to obtain the superclasses of a 646record. It is named ``getSuperClasses`` and returns an ``ArrayRef`` of an 647array of ``std::pair`` pairs. The superclasses are in post-order: the order 648in which the superclasses were visited while copying their fields into the 649record. Each pair consists of a pointer to the ``Record`` instance for a 650superclass record and an instance of the ``SMRange`` class. The range 651indicates the source file locations of the beginning and end of the class 652definition. 653 654This example obtains the superclasses of the ``Prototype`` record and then 655iterates over the pairs in the returned array. 656 657.. code-block:: text 658 659 ArrayRef<std::pair<Record *, SMRange>> 660 Superclasses = Prototype->getSuperClasses(); 661 for (const auto &SuperPair : Superclasses) { 662 ... 663 } 664 665The ``Record`` class also provides a function, ``getDirectSuperClasses``, to 666append the *direct* superclasses of a record to a given vector of type 667``SmallVectorImpl<Record *>``. 668 669Emitting Text to the Output Stream 670================================== 671 672The ``run`` function is passed a ``raw_ostream`` to which it prints the 673output file. By convention, this stream is saved in the emitter class member 674named ``OS``, although some ``run`` functions are simple and just use the 675stream without saving it. The output can be produced by writing values 676directly to the output stream, or by using the ``std::format()`` or 677``llvm::formatv()`` functions. 678 679.. code-block:: text 680 681 OS << "#ifndef " << NodeName << "\n"; 682 683 OS << format("0x%0*x, ", Digits, Value); 684 685Instances of the following classes can be printed using the ``<<`` operator: 686``RecordKeeper``, 687``Record``, 688``RecTy``, 689``RecordVal``, and 690``Init``. 691 692A constant and two helper functions are provided for producing the output 693file. The constant ``MAX_LINE_LEN`` specifies the maximum length of output 694lines. The helper function ``printLine`` prints a horizontal line comment. 695The helper function ``emitSourceFileHeader`` prints the header comment that 696should be included at the top of every output file. 697 698Printing Error Messages 699======================= 700 701TableGen records are often derived from multiple classes and also often 702defined through a sequence of multiclasses. Because of this, it can be 703difficult for backends to report clear error messages with accurate source 704file locations. To make error reporting easier, five error reporting 705functions are provided, each with four overloads. [all combinations to come] 706 707* ``PrintWarning`` prints a message tagged as a warning. 708 709* ``PrintError`` prints a message tagged as an error. 710 711* ``PrintFatalError`` prints a message tagged as an error and then terminates. 712 713* ``PrintNote`` prints a note. It is often used after one of the previous 714 functions to provide more information. 715 716* ``PrintFatalNote`` prints a note and then terminates. 717 718Each of these five functions is overloaded four times. 719 720* ``PrintError(const Twine &Msg)``: 721 Prints the message with no source file location. 722 723* ``PrintError(ArrayRef<SMLoc> ErrorLoc, const Twine &Msg)``: 724 Prints the message followed by the specified source line, 725 along with a pointer to the item in error. The array of 726 source file locations is typically taken from a ``Record`` instance. 727 728* ``PrintError(const Record *Rec, const Twine &Msg)``: 729 Prints the message followed by the source line associated with the 730 specified record (see `Record`_). 731 732* ``PrintError(const RecordVal *RecVal, const Twine &Msg)``: 733 Prints the message followed by the source line associated with the 734 specified record field (see `RecordVal`_). 735 736Using these functions, the goal is to produce the most specific error report 737possible. 738 739Debugging Tools 740=============== 741 742TableGen provides some tools to aid in debugging backends. 743 744The ``PrintRecords`` Backend 745---------------------------- 746 747The TableGen command option ``--print-records`` invokes a simple backend 748that prints all the classes and records defined in the source files. This is 749the default backend option. The output looks like this: 750 751.. code-block:: text 752 753 ------------- Classes ----------------- 754 ... 755 class XEntry<string XEntry:str = ?, int XEntry:val1 = ?> { // XBase 756 string Str = XEntry:str; 757 bits<8> Val1 = { !cast<bits<8>>(XEntry:val1){7}, ... }; 758 bit Val3 = 1; 759 } 760 ... 761 ------------- Defs ----------------- 762 def ATable { // GenericTable 763 string FilterClass = "AEntry"; 764 string CppTypeName = "AEntry"; 765 list<string> Fields = ["Str", "Val1", "Val2"]; 766 list<string> PrimaryKey = ["Val1", "Val2"]; 767 string PrimaryKeyName = "lookupATableByValues"; 768 bit PrimaryKeyEarlyOut = 0; 769 } 770 ... 771 def anonymous_0 { // AEntry 772 string Str = "Bob"; 773 bits<8> Val1 = { 0, 0, 0, 0, 0, 1, 0, 1 }; 774 bits<10> Val2 = { 0, 0, 0, 0, 0, 0, 0, 0, 1, 1 }; 775 } 776 777Classes are shown with their template arguments, parent classes (following 778``//``), and fields. Records are shown with their parent classes and 779fields. Note that anonymous records are named ``anonymous_0``, 780``anonymous_1``, etc. 781 782 783 784The ``PrintDetailedRecords`` Backend 785------------------------------------ 786 787[to come] 788