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.