[llvm] b9eecbf - [TableGen] Update documents to make them more complete
Paul C. Anagnostopoulos via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 22 10:19:51 PDT 2020
Author: Paul C. Anagnostopoulos
Date: 2020-10-22T13:19:19-04:00
New Revision: b9eecbfada4f4e7e8b74434b4fc538d325d95cfc
URL: https://github.com/llvm/llvm-project/commit/b9eecbfada4f4e7e8b74434b4fc538d325d95cfc
DIFF: https://github.com/llvm/llvm-project/commit/b9eecbfada4f4e7e8b74434b4fc538d325d95cfc.diff
LOG: [TableGen] Update documents to make them more complete
Differential Revision: https://reviews.llvm.org/D89962
Added:
Modified:
llvm/docs/TableGen/BackEnds.rst
llvm/docs/TableGen/BackGuide.rst
llvm/docs/TableGen/index.rst
Removed:
################################################################################
diff --git a/llvm/docs/TableGen/BackEnds.rst b/llvm/docs/TableGen/BackEnds.rst
index 1a142614f677..b4ccdf95485e 100644
--- a/llvm/docs/TableGen/BackEnds.rst
+++ b/llvm/docs/TableGen/BackEnds.rst
@@ -29,16 +29,17 @@ MLIR uses TableGen to define operations, operation dialects, and operation
traits.
See the :doc:`TableGen Programmer's Reference <./ProgRef>` for an in-depth
-description of TableGen, and :doc:`TableGen Backend Developer's Guide
+description of TableGen, and the :doc:`TableGen Backend Developer's Guide
<./BackGuide>` for a guide to writing a new backend.
LLVM BackEnds
=============
.. warning::
- This document is raw. Each section below needs three sub-sections: description
- of its purpose with a list of users, output generated from generic input, and
- finally why it needed a new backend (in case there's something similar).
+ This portion is incomplete. Each section below needs three subsections:
+ description of its purpose with a list of users, output generated from
+ generic input, and finally why it needed a new backend (in case there's
+ something similar).
Overall, each backend will take the same TableGen file type and transform into
similar output for
diff erent targets/uses. There is an implicit contract between
@@ -444,6 +445,141 @@ used for documenting user-facing attributes.
General BackEnds
================
+Print Records
+-------------
+
+The TableGen command option ``--print-records`` invokes a simple backend
+that prints all the classes and records defined in the source files. This is
+the default backend option. See the :doc:`TableGen Backend Developer's Guide
+<./BackGuide>` for more information.
+
+Print Detailed Records
+----------------------
+
+The TableGen command option ``--print-detailed-records`` invokes a backend
+that prints all the global variables, classes, and records defined in the
+source files, with more detail than the default record printer. See the
+:doc:`TableGen Backend Developer's Guide <./BackGuide>` for more
+information.
+
+JSON Reference
+--------------
+
+**Purpose**: Output all the values in every ``def``, as a JSON data
+structure that can be easily parsed by a variety of languages. Useful
+for writing custom backends without having to modify TableGen itself,
+or for performing auxiliary analysis on the same TableGen data passed
+to a built-in backend.
+
+**Output**:
+
+The root of the output file is a JSON object (i.e. dictionary),
+containing the following fixed keys:
+
+* ``!tablegen_json_version``: a numeric version field that will
+ increase if an incompatible change is ever made to the structure of
+ this data. The format described here corresponds to version 1.
+
+* ``!instanceof``: a dictionary whose keys are the class names defined
+ in the TableGen input. For each key, the corresponding value is an
+ array of strings giving the names of ``def`` records that derive
+ from that class. So ``root["!instanceof"]["Instruction"]``, for
+ example, would list the names of all the records deriving from the
+ class ``Instruction``.
+
+For each ``def`` record, the root object also has a key for the record
+name. The corresponding value is a subsidiary object containing the
+following fixed keys:
+
+* ``!superclasses``: an array of strings giving the names of all the
+ classes that this record derives from.
+
+* ``!fields``: an array of strings giving the names of all the variables
+ in this record that were defined with the ``field`` keyword.
+
+* ``!name``: a string giving the name of the record. This is always
+ identical to the key in the JSON root object corresponding to this
+ record's dictionary. (If the record is anonymous, the name is
+ arbitrary.)
+
+* ``!anonymous``: a boolean indicating whether the record's name was
+ specified by the TableGen input (if it is ``false``), or invented by
+ TableGen itself (if ``true``).
+
+For each variable defined in a record, the ``def`` object for that
+record also has a key for the variable name. The corresponding value
+is a translation into JSON of the variable's value, using the
+conventions described below.
+
+Some TableGen data types are translated directly into the
+corresponding JSON type:
+
+* A completely undefined value (e.g. for a variable declared without
+ initializer in some superclass of this record, and never initialized
+ by the record itself or any other superclass) is emitted as the JSON
+ ``null`` value.
+
+* ``int`` and ``bit`` values are emitted as numbers. Note that
+ TableGen ``int`` values are capable of holding integers too large to
+ be exactly representable in IEEE double precision. The integer
+ literal in the JSON output will show the full exact integer value.
+ So if you need to retrieve large integers with full precision, you
+ should use a JSON reader capable of translating such literals back
+ into 64-bit integers without losing precision, such as Python's
+ standard ``json`` module.
+
+* ``string`` and ``code`` values are emitted as JSON strings.
+
+* ``list<T>`` values, for any element type ``T``, are emitted as JSON
+ arrays. Each element of the array is represented in turn using these
+ same conventions.
+
+* ``bits`` values are also emitted as arrays. A ``bits`` array is
+ ordered from least-significant bit to most-significant. So the
+ element with index ``i`` corresponds to the bit described as
+ ``x{i}`` in TableGen source. However, note that this means that
+ scripting languages are likely to *display* the array in the
+ opposite order from the way it appears in the TableGen source or in
+ the diagnostic ``-print-records`` output.
+
+All other TableGen value types are emitted as a JSON object,
+containing two standard fields: ``kind`` is a discriminator describing
+which kind of value the object represents, and ``printable`` is a
+string giving the same representation of the value that would appear
+in ``-print-records``.
+
+* A reference to a ``def`` object has ``kind=="def"``, and has an
+ extra field ``def`` giving the name of the object referred to.
+
+* A reference to another variable in the same record has
+ ``kind=="var"``, and has an extra field ``var`` giving the name of
+ the variable referred to.
+
+* A reference to a specific bit of a ``bits``-typed variable in the
+ same record has ``kind=="varbit"``, and has two extra fields:
+ ``var`` gives the name of the variable referred to, and ``index``
+ gives the index of the bit.
+
+* A value of type ``dag`` has ``kind=="dag"``, and has two extra
+ fields. ``operator`` gives the initial value after the opening
+ parenthesis of the dag initializer; ``args`` is an array giving the
+ following arguments. The elements of ``args`` are arrays of length
+ 2, giving the value of each argument followed by its colon-suffixed
+ name (if any). For example, in the JSON representation of the dag
+ value ``(Op 22, "hello":$foo)`` (assuming that ``Op`` is the name of
+ a record defined elsewhere with a ``def`` statement):
+
+ * ``operator`` will be an object in which ``kind=="def"`` and
+ ``def=="Op"``
+
+ * ``args`` will be the array ``[[22, null], ["hello", "foo"]]``.
+
+* If any other kind of value or complicated expression appears in the
+ output, it will have ``kind=="complex"``, and no additional fields.
+ These values are not expected to be needed by backends. The standard
+ ``printable`` field can be used to extract a representation of them
+ in TableGen source syntax if necessary.
+
SearchableTables Reference
--------------------------
@@ -819,120 +955,3 @@ This use of ``SearchIndex`` generates the following additional C++ code.
return &CTable[Idx->_index];
}
-JSON
-----
-
-**Purpose**: Output all the values in every ``def``, as a JSON data
-structure that can be easily parsed by a variety of languages. Useful
-for writing custom backends without having to modify TableGen itself,
-or for performing auxiliary analysis on the same TableGen data passed
-to a built-in backend.
-
-**Output**:
-
-The root of the output file is a JSON object (i.e. dictionary),
-containing the following fixed keys:
-
-* ``!tablegen_json_version``: a numeric version field that will
- increase if an incompatible change is ever made to the structure of
- this data. The format described here corresponds to version 1.
-
-* ``!instanceof``: a dictionary whose keys are the class names defined
- in the TableGen input. For each key, the corresponding value is an
- array of strings giving the names of ``def`` records that derive
- from that class. So ``root["!instanceof"]["Instruction"]``, for
- example, would list the names of all the records deriving from the
- class ``Instruction``.
-
-For each ``def`` record, the root object also has a key for the record
-name. The corresponding value is a subsidiary object containing the
-following fixed keys:
-
-* ``!superclasses``: an array of strings giving the names of all the
- classes that this record derives from.
-
-* ``!fields``: an array of strings giving the names of all the variables
- in this record that were defined with the ``field`` keyword.
-
-* ``!name``: a string giving the name of the record. This is always
- identical to the key in the JSON root object corresponding to this
- record's dictionary. (If the record is anonymous, the name is
- arbitrary.)
-
-* ``!anonymous``: a boolean indicating whether the record's name was
- specified by the TableGen input (if it is ``false``), or invented by
- TableGen itself (if ``true``).
-
-For each variable defined in a record, the ``def`` object for that
-record also has a key for the variable name. The corresponding value
-is a translation into JSON of the variable's value, using the
-conventions described below.
-
-Some TableGen data types are translated directly into the
-corresponding JSON type:
-
-* A completely undefined value (e.g. for a variable declared without
- initializer in some superclass of this record, and never initialized
- by the record itself or any other superclass) is emitted as the JSON
- ``null`` value.
-
-* ``int`` and ``bit`` values are emitted as numbers. Note that
- TableGen ``int`` values are capable of holding integers too large to
- be exactly representable in IEEE double precision. The integer
- literal in the JSON output will show the full exact integer value.
- So if you need to retrieve large integers with full precision, you
- should use a JSON reader capable of translating such literals back
- into 64-bit integers without losing precision, such as Python's
- standard ``json`` module.
-
-* ``string`` and ``code`` values are emitted as JSON strings.
-
-* ``list<T>`` values, for any element type ``T``, are emitted as JSON
- arrays. Each element of the array is represented in turn using these
- same conventions.
-
-* ``bits`` values are also emitted as arrays. A ``bits`` array is
- ordered from least-significant bit to most-significant. So the
- element with index ``i`` corresponds to the bit described as
- ``x{i}`` in TableGen source. However, note that this means that
- scripting languages are likely to *display* the array in the
- opposite order from the way it appears in the TableGen source or in
- the diagnostic ``-print-records`` output.
-
-All other TableGen value types are emitted as a JSON object,
-containing two standard fields: ``kind`` is a discriminator describing
-which kind of value the object represents, and ``printable`` is a
-string giving the same representation of the value that would appear
-in ``-print-records``.
-
-* A reference to a ``def`` object has ``kind=="def"``, and has an
- extra field ``def`` giving the name of the object referred to.
-
-* A reference to another variable in the same record has
- ``kind=="var"``, and has an extra field ``var`` giving the name of
- the variable referred to.
-
-* A reference to a specific bit of a ``bits``-typed variable in the
- same record has ``kind=="varbit"``, and has two extra fields:
- ``var`` gives the name of the variable referred to, and ``index``
- gives the index of the bit.
-
-* A value of type ``dag`` has ``kind=="dag"``, and has two extra
- fields. ``operator`` gives the initial value after the opening
- parenthesis of the dag initializer; ``args`` is an array giving the
- following arguments. The elements of ``args`` are arrays of length
- 2, giving the value of each argument followed by its colon-suffixed
- name (if any). For example, in the JSON representation of the dag
- value ``(Op 22, "hello":$foo)`` (assuming that ``Op`` is the name of
- a record defined elsewhere with a ``def`` statement):
-
- * ``operator`` will be an object in which ``kind=="def"`` and
- ``def=="Op"``
-
- * ``args`` will be the array ``[[22, null], ["hello", "foo"]]``.
-
-* If any other kind of value or complicated expression appears in the
- output, it will have ``kind=="complex"``, and no additional fields.
- These values are not expected to be needed by backends. The standard
- ``printable`` field can be used to extract a representation of them
- in TableGen source syntax if necessary.
diff --git a/llvm/docs/TableGen/BackGuide.rst b/llvm/docs/TableGen/BackGuide.rst
index 3a84babc4c39..0463c96b5794 100644
--- a/llvm/docs/TableGen/BackGuide.rst
+++ b/llvm/docs/TableGen/BackGuide.rst
@@ -27,7 +27,7 @@ header file (``record.h``) and/or the Doxygen documentation.
This document assumes that you have read the :doc:`TableGen Programmer's
Reference <./ProgRef>`, which provides a detailed reference for coding
-TableGen source files. This document and the relevant Doxygen pages will be
+TableGen source files. This document and the data structure comments will be
improved over time.
Data Structures
diff --git a/llvm/docs/TableGen/index.rst b/llvm/docs/TableGen/index.rst
index fd4333dbef5f..8eaaa37489e7 100644
--- a/llvm/docs/TableGen/index.rst
+++ b/llvm/docs/TableGen/index.rst
@@ -261,9 +261,9 @@ description of TableGen.
TableGen backends
=================
-TableGen files have no real meaning without a back-end. The default operation
-of running ``llvm-tblgen`` is to print the information in a textual format, but
-that's only useful for debugging of the TableGen files themselves. The power
+TableGen files have no real meaning without a backend. The default operation
+when running ``xxx-tblgen`` is to print the information in a textual format, but
+that's only useful for debugging the TableGen files themselves. The power
in TableGen is, however, to interpret the source files into an internal
representation that can be generated into anything you want.
@@ -271,15 +271,15 @@ Current usage of TableGen is to create huge include files with tables that you
can either include directly (if the output is in the language you're coding),
or be used in pre-processing via macros surrounding the include of the file.
-Direct output can be used if the back-end already prints a table in C format
+Direct output can be used if the backend already prints a table in C format
or if the output is just a list of strings (for error and warning messages).
Pre-processed output should be used if the same information needs to be used
-in
diff erent contexts (like Instruction names), so your back-end should print
+in
diff erent contexts (like Instruction names), so your backend should print
a meta-information list that can be shaped into
diff erent compile-time formats.
See :doc:`TableGen BackEnds <./BackEnds>` for a list of available
backends, and see the :doc:`TableGen Backend Developer's Guide <./BackGuide>`
-for information on how to write a new backend.
+for information on how to write and debug a new backend.
TableGen Deficiencies
=====================
@@ -291,12 +291,12 @@ lack the power of other DSLs, which in turn increase considerably the size
and complexity of TableGen files.
At the same time, TableGen allows you to create virtually any meaning of
-the basic concepts via custom-made back-ends, which can pervert the original
+the basic concepts via custom-made backends, which can pervert the original
design and make it very hard for newcomers to understand the evil TableGen
file.
There are some in favour of extending the semantics even more, but making sure
-back-ends adhere to strict rules. Others are suggesting we should move to less,
+backends adhere to strict rules. Others are suggesting we should move to less,
more powerful DSLs designed with specific purposes, or even re-using existing
DSLs.
More information about the llvm-commits
mailing list