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, by name. 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 referred 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 subclasses, one 256for each of the available value types. The primary data member of ``Init`` 257is an enumerated type that represents the specific type of the value. 258 259The ``Init`` class provides a few useful functions. 260 261* A function to get the type enumerator. 262 263* A boolean virtual function to determine whether a value is completely 264 specified; that is, has no uninitialized subvalues. 265 266* Virtual functions to get the value as a string. 267 268* Virtual functions to cast the value to other types, implement the bit 269 range feature of TableGen, and implement the list slice feature. 270 271* A virtual function to get a particular bit of the value. 272 273The subclasses that inherit directly from ``Init`` are 274``UnsetInit`` and ``TypedInit``. 275 276An ``Init`` instance can be printed to an output stream with the ``<<`` 277operator. 278 279.. warning:: 280 It is not specified whether two separate initialization values with 281 the same underlying type and value (e.g., two strings with the value 282 "Hello") are represented by two ``Init``\ s or share the same ``Init``. 283 284``UnsetInit`` 285~~~~~~~~~~~~~ 286 287This class, a subclass of ``Init``, represents the unset (uninitialized) 288value. The static function ``get()`` can be used to obtain the singleton 289``Init`` of this type. 290 291 292``TypedInit`` 293~~~~~~~~~~~~~ 294 295This class, a subclass of ``Init``, acts as the parent class of the classes 296that represent specific value types (except for the unset value). These 297classes include ``BitInit``, ``BitsInit``, ``CodeInit``, ``DagInit``, 298``DefInit``, ``IntInit``, ``ListInit``, and ``StringInit``. (There are 299additional derived types used by the TableGen parser.) 300 301This class includes a data member that specifies the ``RecTy`` type of the 302value. It provides a function to get that ``RecTy`` type. 303 304``BitInit`` 305~~~~~~~~~~~ 306 307The ``BitInit`` class is a subclass of ``TypedInit``. Its instances 308represent the possible values of a bit: 0 or 1. It includes a data member 309that contains the bit. 310 311*All* of the classes derived from ``TypedInit`` provide the following functions. 312 313* A static function named ``get()`` that returns an ``Init`` representing 314 the specified value(s). In the case of ``BitInit``, ``get(true)`` returns 315 an instance of ``BitInit`` representing true, while ``get(false)`` returns 316 an instance 317 representing false. As noted above, it is not specified whether there 318 is exactly one or more than one ``BitInit`` representing true (or false). 319 320* A function named ``GetValue()`` that returns the value of the instance 321 in a more direct form, in this case as a ``bool``. 322 323``BitsInit`` 324~~~~~~~~~~~~ 325 326The ``BitsInit`` class is a subclass of ``TypedInit``. Its instances 327represent sequences of bits, from high-order to low-order. It includes a 328data member with the length of the sequence and a vector of pointers to 329``Init`` instances, one per bit. 330 331The class provides the usual ``get()`` function. It does not provide the 332``getValue()`` function. 333 334The class provides the following additional functions. 335 336* A function to get the number of bits in the sequence. 337 338* A function that gets a bit specified by an integer index. 339 340``CodeInit`` 341~~~~~~~~~~~~ 342 343The ``CodeInit`` class is a subclass of ``TypedInit``. Its instances 344represent arbitrary-length strings produced from ``code`` literals in the 345TableGen files. It includes a data member that contains a ``StringRef`` of 346the value. It also includes a data member specifying the source code 347location of the code string. 348 349The class provides the usual ``get()`` and ``getValue()`` functions. The 350latter function returns the ``StringRef``. 351 352The ``getLoc()`` function returns the source code location. 353 354 355``DagInit`` 356~~~~~~~~~~~ 357 358The ``DagInit`` class is a subclass of ``TypedInit``. Its instances 359represent the possible direct acyclic graphs (``dag``). 360 361The class includes a pointer to an ``Init`` for the DAG operator and a 362pointer to a ``StringInit`` for the operator name. It includes the count of 363DAG operands and the count of operand names. Finally, it includes a vector of 364pointers to ``Init`` instances for the operands and another to 365``StringInit`` instances for the operand names. 366(The DAG operands are also referred to as *arguments*.) 367 368The class provides two forms of the usual ``get()`` function. It does not 369provide the usual ``getValue()`` function. 370 371The class provides many additional functions: 372 373* Functions to get the operator in various forms and to get the 374 operator name in various forms. 375 376* Functions to determine whether there are any operands and to get the 377 number of operands. 378 379* Functions to the get the operands, both individually and together. 380 381* Functions to determine whether there are any names and to 382 get the number of names 383 384* Functions to the get the names, both individually and together. 385 386* Functions to get the operand iterator ``begin()`` and ``end()`` values. 387 388* Functions to get the name iterator ``begin()`` and ``end()`` values. 389 390The class defines two types for the return values of the operand and name 391iterators. 392 393.. code-block:: text 394 395 using const_arg_iterator = SmallVectorImpl<Init*>::const_iterator; 396 using const_name_iterator = SmallVectorImpl<StringInit*>::const_iterator; 397 398 399``DefInit`` 400~~~~~~~~~~~ 401 402The ``DefInit`` class is a subclass of ``TypedInit``. Its instances 403represent the records that were collected by TableGen. It includes a data 404member that is a pointer to the record's ``Record`` instance. 405 406The class provides the usual ``get()`` function. It does not provide 407``getValue()``. Instead, it provides ``getDef()``, which returns the 408``Record`` instance. 409 410``IntInit`` 411~~~~~~~~~~~ 412 413The ``IntInit`` class is a subclass of ``TypedInit``. Its instances 414represent the possible values of a 64-bit integer. It includes a data member 415that contains the integer. 416 417The class provides the usual ``get()`` and ``getValue()`` functions. The 418latter function returns the integer as an ``int64_t``. 419 420The class also provides a function, ``getBit()``, to obtain a specified bit 421of the integer value. 422 423``ListInit`` 424~~~~~~~~~~~~ 425 426The ``ListInit`` class is a subclass of ``TypedInit``. Its instances 427represent lists of elements of some type. It includes a data member with the 428length of the list and a vector of pointers to ``Init`` instances, one per 429element. 430 431The class provides the usual ``get()`` and ``getValues()`` functions. The 432latter function returns an ``ArrayRef`` of the vector of pointers to ``Init`` 433instances. 434 435The class provides these additional functions. 436 437* A function to get the element type. 438 439* Functions to get the length of the vector and to determine whether 440 it is empty. 441 442* Functions to get an element specified by an integer index and return 443 it in various forms. 444 445* Functions to get the iterator ``begin()`` and ``end()`` values. The 446 class defines a type for the return type of these two functions. 447 448.. code-block:: text 449 450 using const_iterator = Init *const *; 451 452 453``StringInit`` 454~~~~~~~~~~~~~~ 455 456The ``StringInit`` class is a subclass of ``TypedInit``. Its instances 457represent arbitrary-length strings. It includes a data member 458that contains a ``StringRef`` of the value. 459 460The class provides the usual ``get()`` and ``getValue()`` functions. The 461latter function returns the ``StringRef``. 462 463Creating a New Backend 464====================== 465 466The following steps are required to create a new backend for TableGen. 467 468#. Invent a name for your backend C++ file, say ``GenAddressModes``. 469 470#. Write the new backend, using the file ``TableGenBackendSkeleton.cpp`` 471 as a starting point. 472 473#. Determine which instance of TableGen requires the new backend. There is 474 one instance for Clang and another for LLVM. Or you may be building 475 your own instance. 476 477#. Modify the selected ``tablegen.cpp`` to include your new backend. 478 479 a. Add the name to the enumerated type ``ActionType``. 480 481 #. Add a keyword to the ``ActionType`` command option using the 482 ``clEnumValN()`` function. 483 484 #. Add a case to the ``switch`` statement in the *xxx*\ ``TableGenMain()`` 485 function. It should invoke the "main function" of your backend, which 486 in this case, according to convention, is named ``EmitAddressModes``. 487 4885. Add a declaration of your "main function" to the corresponding 489 ``TableGenBackends.h`` header file. 490 491#. Add your backend C++ file to the appropriate ``CMakeLists.txt`` file so 492 that it will be built. 493 494#. Add your C++ file to the system. 495 496The Backend Skeleton 497==================== 498 499The file ``TableGenBackendSkeleton.cpp`` provides a skeleton C++ translation 500unit for writing a new TableGen backend. Here are a few notes on the file. 501 502* The list of includes is the minimal list required by most backends. 503 504* As with all LLVM C++ files, it has a ``using namespace llvm;`` statement. 505 It also has an anonymous namespace that contains all the file-specific 506 data structure definitions, along with the class embodying the emitter 507 data members and functions. Continuing with the ``GenAddressModes`` example, 508 this class is named ``AddressModesEmitter``. 509 510* The constructor for the emitter class accepts a ``RecordKeeper`` reference, 511 typically named ``RK``. The ``RecordKeeper`` reference is saved in a data 512 member so that records can be obtained from it. This data member is usually 513 named ``Records``. 514 515* One function is named ``run``. It is invoked by the backend's "main 516 function" to collect records and emit the output file. It accepts an instance 517 of the ``raw_ostream`` class, typically named ``OS``. The output file is 518 emitted by writing to this stream. 519 520* The ``run`` function should use the ``emitSourceFileHeader`` helper function 521 to include a standard header in the emitted file. 522 523* The only function in the ``llvm`` namespace is the backend "main function." 524 In this example, it is named ``EmitAddressModes``. It creates an instance 525 of the ``AddressModesEmitter`` class, passing the ``RecordKeeper`` 526 instance, then invokes the ``run`` function, passing the ``raw_ostream`` 527 instance. 528 529All the examples in the remainder of this document will assume the naming 530conventions used in the skeleton file. 531 532Getting Classes 533=============== 534 535The ``RecordKeeper`` class provides two functions for getting the 536``Record`` instances for classes defined in the TableGen files. 537 538* ``getClasses()`` returns a ``RecordMap`` reference for all the classes. 539 540* ``getClass(``\ *name*\ ``)`` returns a ``Record`` reference for the named 541 class. 542 543If you need to iterate over all the class records: 544 545.. code-block:: text 546 547 for (auto ClassPair : Records.getClasses()) { 548 Record *ClassRec = ClassPair.second.get(); 549 ... 550 } 551 552``ClassPair.second`` gets the class's ``unique_ptr``, then ``.get()`` gets the 553class ``Record`` itself. 554 555 556Getting Records 557=============== 558 559The ``RecordKeeper`` class provides four functions for getting the 560``Record`` instances for concrete records defined in the TableGen files. 561 562* ``getDefs()`` returns a ``RecordMap`` reference for all the concrete 563 records. 564 565* ``getDef(``\ *name*\ ``)`` return a ``Record`` reference for the named 566 concrete record. 567 568* ``getAllDerivedDefinitions(``\ *classname*\ ``)`` returns a vector of 569 ``Record`` references for the concrete records that derive from the 570 given class. 571 572* ``getAllDerivedDefinitionsTwo(``\ *classname1*\ ``,`` *classname2*\ ``)`` returns 573 a vector of ``Record`` references for the concrete records that derive from 574 *both* of the given classes. [function to come] 575 576This statement obtains all the records that derive from the ``Attribute`` 577class and iterates over them. 578 579.. code-block:: text 580 581 auto AttrRecords = Records.getAllDerivedDefinitions("Attribute"); 582 for (Record *AttrRec : AttrRecords) { 583 ... 584 } 585 586Getting Record Names and Fields 587=============================== 588 589As described above (see `Record`_), there are multiple functions that 590return the name of a record. One particularly useful one is 591``getNameInitAsString()``, which returns the name as a ``std::string``. 592 593There are also multiple functions that return the fields of a record. To 594obtain and iterate over all the fields: 595 596.. code-block:: text 597 598 for (const RecordVal &Field : SomeRec->getValues()) { 599 ... 600 } 601 602You will recall that ``RecordVal`` is the class whose instances contain 603information about the fields in records. 604 605The ``getValue()`` function returns the ``RecordVal`` instance for a field 606specified by name. There are multiple overloaded functions, some taking a 607``StringRef`` and others taking a ``const Init *``. Some functions return a 608``RecordVal *`` and others return a ``const RecordVal *``. If the field does 609not exist, a fatal error message is printed. 610 611More often than not, you are interested in the value of the field, not all 612the information in the ``RecordVal``. There is a large set of functions that 613take a field name in some form and return its value. One function, 614``getValueInit``, returns the value as an ``Init *``. Another function, 615``isValueUnset``, returns a boolean specifying whether the value is unset 616(uninitialized). 617 618Most of the functions return the value in some more useful form. For 619example: 620 621.. code-block:: text 622 623 std::vector<int64_t> RegCosts = 624 SomeRec->getValueAsListOfInts("RegCosts"); 625 626The field ``RegCosts`` is assumed to be a list of integers. That list is 627returned as a ``std::vector`` of 64-bit integers. If the field is not a list 628of integers, a fatal error message is printed. 629 630Here is a function that returns a field value as a ``Record``, but returns 631null if the field does not exist. 632 633.. code-block:: text 634 635 if (Record *BaseRec = SomeRec->getValueAsOptionalDef(BaseFieldName)) { 636 ... 637 } 638 639The field is assumed to have another record as its value. That record is returned 640as a pointer to a ``Record``. If the field does not exist or is unset, the 641functions returns null. 642 643Getting Record Superclasses 644=========================== 645 646The ``Record`` class provides a function to obtain the superclasses of a 647record. It is named ``getSuperClasses`` and returns an ``ArrayRef`` of an 648array of ``std::pair`` pairs. The superclasses are in post-order: the order 649in which the superclasses were visited while copying their fields into the 650record. Each pair consists of a pointer to the ``Record`` instance for a 651superclass record and an instance of the ``SMRange`` class. The range 652indicates the source file locations of the beginning and end of the class 653definition. 654 655This example obtains the superclasses of the ``Prototype`` record and then 656iterates over the pairs in the returned array. 657 658.. code-block:: text 659 660 ArrayRef<std::pair<Record *, SMRange>> 661 Superclasses = Prototype->getSuperClasses(); 662 for (const auto &SuperPair : Superclasses) { 663 ... 664 } 665 666The ``Record`` class also provides a function, ``getDirectSuperClasses``, to 667append the *direct* superclasses of a record to a given vector of type 668``SmallVectorImpl<Record *>``. 669 670Emitting Text to the Output Stream 671================================== 672 673The ``run`` function is passed a ``raw_ostream`` to which it prints the 674output file. By convention, this stream is saved in the emitter class member 675named ``OS``, although some ``run`` functions are simple and just use the 676stream without saving it. The output can be produced by writing values 677directly to the output stream, or by using the ``std::format()`` or 678``llvm::formatv()`` functions. 679 680.. code-block:: text 681 682 OS << "#ifndef " << NodeName << "\n"; 683 684 OS << format("0x%0*x, ", Digits, Value); 685 686Instances of the following classes can be printed using the ``<<`` operator: 687``RecordKeeper``, 688``Record``, 689``RecTy``, 690``RecordVal``, and 691``Init``. 692 693The helper function ``emitSourceFileHeader()`` prints the header comment 694that should be included at the top of every output file. A call to it is 695included in the skeleton backend file ``TableGenBackendSkeleton.cpp``. 696 697Printing Error Messages 698======================= 699 700TableGen records are often derived from multiple classes and also often 701defined through a sequence of multiclasses. Because of this, it can be 702difficult for backends to report clear error messages with accurate source 703file locations. To make error reporting easier, five error reporting 704functions are provided, each with four overloads. [all combinations to come] 705 706* ``PrintWarning`` prints a message tagged as a warning. 707 708* ``PrintError`` prints a message tagged as an error. 709 710* ``PrintFatalError`` prints a message tagged as an error and then terminates. 711 712* ``PrintNote`` prints a note. It is often used after one of the previous 713 functions to provide more information. 714 715* ``PrintFatalNote`` prints a note and then terminates. 716 717Each of these five functions is overloaded four times. 718 719* ``PrintError(const Twine &Msg)``: 720 Prints the message with no source file location. 721 722* ``PrintError(ArrayRef<SMLoc> ErrorLoc, const Twine &Msg)``: 723 Prints the message followed by the specified source line, 724 along with a pointer to the item in error. The array of 725 source file locations is typically taken from a ``Record`` instance. 726 727* ``PrintError(const Record *Rec, const Twine &Msg)``: 728 Prints the message followed by the source line associated with the 729 specified record (see `Record`_). 730 731* ``PrintError(const RecordVal *RecVal, const Twine &Msg)``: 732 Prints the message followed by the source line associated with the 733 specified record field (see `RecordVal`_). 734 735Using these functions, the goal is to produce the most specific error report 736possible. 737 738Debugging Tools 739=============== 740 741TableGen provides some tools to aid in debugging backends. 742 743The ``PrintRecords`` Backend 744---------------------------- 745 746The TableGen command option ``--print-records`` invokes a simple backend 747that prints all the classes and records defined in the source files. This is 748the default backend option. The output looks like this: 749 750.. code-block:: text 751 752 ------------- Classes ----------------- 753 ... 754 class XEntry<string XEntry:str = ?, int XEntry:val1 = ?> { // XBase 755 string Str = XEntry:str; 756 bits<8> Val1 = { !cast<bits<8>>(XEntry:val1){7}, ... }; 757 bit Val3 = 1; 758 } 759 ... 760 ------------- Defs ----------------- 761 def ATable { // GenericTable 762 string FilterClass = "AEntry"; 763 string CppTypeName = "AEntry"; 764 list<string> Fields = ["Str", "Val1", "Val2"]; 765 list<string> PrimaryKey = ["Val1", "Val2"]; 766 string PrimaryKeyName = "lookupATableByValues"; 767 bit PrimaryKeyEarlyOut = 0; 768 } 769 ... 770 def anonymous_0 { // AEntry 771 string Str = "Bob"; 772 bits<8> Val1 = { 0, 0, 0, 0, 0, 1, 0, 1 }; 773 bits<10> Val2 = { 0, 0, 0, 0, 0, 0, 0, 0, 1, 1 }; 774 } 775 776Classes are shown with their template arguments, parent classes (following 777``//``), and fields. Records are shown with their parent classes and 778fields. Note that anonymous records are named ``anonymous_0``, 779``anonymous_1``, etc. 780 781The ``PrintDetailedRecords`` Backend 782------------------------------------ 783 784The TableGen command option ``--print-detailed-records`` invokes a backend 785that prints all the global variables, classes, and records defined in the 786source files. The output looks like this. 787 788.. code-block:: text 789 790 DETAILED RECORDS for file llvm-project\llvm\lib\target\arc\arc.td 791 792 -------------------- Global Variables (5) -------------------- 793 794 AMDGPUBufferIntrinsics = [int_amdgcn_buffer_load_format, ... 795 AMDGPUImageDimAtomicIntrinsics = [int_amdgcn_image_atomic_swap_1d, ... 796 ... 797 -------------------- Classes (758) -------------------- 798 799 AMDGPUBufferLoad |IntrinsicsAMDGPU.td:879| 800 Template args: 801 LLVMType AMDGPUBufferLoad:data_ty = llvm_any_ty |IntrinsicsAMDGPU.td:879| 802 Superclasses: (SDPatternOperator) Intrinsic AMDGPURsrcIntrinsic 803 Fields: 804 list<SDNodeProperty> Properties = [SDNPMemOperand] |Intrinsics.td:348| 805 string LLVMName = "" |Intrinsics.td:343| 806 ... 807 -------------------- Records (12303) -------------------- 808 809 AMDGPUSample_lz_o |IntrinsicsAMDGPU.td:560| 810 Defm sequence: |IntrinsicsAMDGPU.td:584| |IntrinsicsAMDGPU.td:566| 811 Superclasses: AMDGPUSampleVariant 812 Fields: 813 string UpperCaseMod = "_LZ_O" |IntrinsicsAMDGPU.td:542| 814 string LowerCaseMod = "_lz_o" |IntrinsicsAMDGPU.td:543| 815 ... 816 817* Global variables defined with outer ``defvar`` statements are shown with 818 their values. 819 820* The classes are shown with their source location, template arguments, 821 superclasses, and fields. 822 823* The records are shown with their source location, ``defm`` sequence, 824 superclasses, and fields. 825 826Superclasses are shown in the order processed, with indirect superclasses in 827parentheses. Each field is shown with its value and the source location at 828which it was set. 829The ``defm`` sequence gives the locations of the ``defm`` statements that 830were involved in generating the record, in the order they were invoked.