Lines Matching refs:records
16 information is coded in a declarative style involving classes and records,
17 which are then processed by TableGen. The internalized records are passed on
18 to various *backends*, which extract information from a subset of the records
56 TableGen source files contain two primary items: *abstract records* and
57 *concrete records*. In this and other TableGen documents, abstract records
59 not map onto them.) In addition, concrete records are usually just called
60 records, although sometimes the term *record* refers to both classes and
61 concrete records. The distinction should be clear in context.
63 Classes and concrete records have a unique *name*, either chosen by
76 concrete records similarly.
78 A backend processes some subset of the concrete records built by the
81 those records. However, a backend can produce any type of output files. For
84 LLVM code generator, there can be many concrete records and some of them can
104 Both classes and concrete records can include fields that are uninitialized.
107 classes are inherited by concrete records. Even so, some fields of concrete
108 records may remain uninitialized.
112 multiple concrete records all at once. A multiclass can inherit from other
265 wide range of records conveniently and compactly.
566 classes and records can inherit.
601 forward declaration. Note that records derived from a forward-declared
602 class will inherit no fields from it, because those records are built when
612 See `Examples: classes and records`_ for examples.
709 records are built`_.
711 See `Examples: classes and records`_ for examples.
714 Examples: classes and records
734 Next, two records are defined, derived from class ``C``; that is, with ``C``
740 A class is useful for isolating the common features of multiple records in
742 records inheriting from that class can override the defaults.
767 eight records is defined with ``FPFormat`` as its parent class. The
775 four records that inherit the ``Value`` field with its four different
792 value into two fields, one bit each. Then we can define records that inherit from
831 ``let`` --- override fields in classes or records
835 *bindings*) and applies them to all the classes and records defined by
849 the classes and records defined in the statements. The field values are
850 applied to the classes and records *after* the records inherit all the fields from
855 overridden in several records. Here are two examples. Note that ``let``
876 Note that a top-level ``let`` will not override fields defined in the classes or records
880 ``multiclass`` --- define multiple records
884 between multiple records, multiclasses allow a convenient method for
885 defining many records at once. For example, consider a 3-address
891 template that expands into multiple records.
904 contains a series of statements that define records, using :token:`Def` and
918 The records defined in a multiclass are created when the multiclass is
927 ``defm`` --- invoke multiclasses to define multiple records
944 This statement instantiates all the records defined in all the specified
946 ``defm`` statements. These records also receive the fields defined in any
948 a common set of fields to all the records created by the ``defm``.
994 // Define records for each instruction in the RR and RI formats.
999 Each use of the ``ri_inst`` multiclass defines two records, one with the
1001 that uses a multiclass is prepended to the names of the records defined in
1026 // Define records for each instruction in the RR and RI formats.
1035 create the records defined in those multiclasses in addition to the records
1067 The final ``defm`` creates the following records, five from the ``basic_s``
1106 This example will create four records, shown here in alphabetical order with
1132 another way to factor out commonality from the records, especially when
1160 The ``defset`` statement is used to collect a set of records into a global
1161 list of records.
1166 All records defined inside the braces via ``def`` and ``defm`` are defined
1176 records to its own set, and all those records are also added to the outer
1179 Anonymous records created inside initialization expressions using the
1239 This loop defines records named ``R0``, ``R1``, ``R2``, and ``R3``, along
1293 the subclasses and records that inherit from the class. The assertions are
1294 then checked when the records are completely built.
1378 How records are built
1382 abstract records and so go through the same steps.
1577 the list of all defined records. The resulting record is expected to be of
1619 same type or be records with a common parent class. Mixing ``dag`` and
1661 list of records in ``RecList``::
1685 DAG operators are always records.
1843 global name. The following records are produced.