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