2013-01-07 03:43:44 +01:00
|
|
|
===========================
|
|
|
|
TableGen Language Reference
|
|
|
|
===========================
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
:local:
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
This document is extremely rough. If you find something lacking, please
|
2015-08-05 05:51:17 +02:00
|
|
|
fix it, file a documentation bug, or ask about it on llvm-dev.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
|
|
|
Introduction
|
|
|
|
============
|
|
|
|
|
|
|
|
This document is meant to be a normative spec about the TableGen language
|
|
|
|
in and of itself (i.e. how to understand a given construct in terms of how
|
|
|
|
it affects the final set of records represented by the TableGen file). If
|
|
|
|
you are unsure if this document is really what you are looking for, please
|
2014-04-08 00:46:40 +02:00
|
|
|
read the :doc:`introduction to TableGen <index>` first.
|
2013-01-09 03:20:30 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Notation
|
|
|
|
========
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
The lexical and syntax notation used here is intended to imitate
|
|
|
|
`Python's`_. In particular, for lexical definitions, the productions
|
|
|
|
operate at the character level and there is no implied whitespace between
|
|
|
|
elements. The syntax definitions operate at the token level, so there is
|
|
|
|
implied whitespace between tokens.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. _`Python's`: http://docs.python.org/py3k/reference/introduction.html#notation
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Lexical Analysis
|
|
|
|
================
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen supports BCPL (``// ...``) and nestable C-style (``/* ... */``)
|
|
|
|
comments.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
The following is a listing of the basic punctuation tokens::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
- + [ ] { } ( ) < > : ; . = ? #
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Numeric literals take one of the following forms:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. TableGen actually will lex some pretty strange sequences an interpret
|
|
|
|
them as numbers. What is shown here is an attempt to approximate what it
|
|
|
|
"should" accept.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
TokInteger: `DecimalInteger` | `HexInteger` | `BinInteger`
|
|
|
|
DecimalInteger: ["+" | "-"] ("0"..."9")+
|
|
|
|
HexInteger: "0x" ("0"..."9" | "a"..."f" | "A"..."F")+
|
|
|
|
BinInteger: "0b" ("0" | "1")+
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
One aspect to note is that the :token:`DecimalInteger` token *includes* the
|
|
|
|
``+`` or ``-``, as opposed to having ``+`` and ``-`` be unary operators as
|
|
|
|
most languages do.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-08-07 07:47:13 +02:00
|
|
|
Also note that :token:`BinInteger` creates a value of type ``bits<n>``
|
|
|
|
(where ``n`` is the number of bits). This will implicitly convert to
|
|
|
|
integers when needed.
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen has identifier-like tokens:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
ualpha: "a"..."z" | "A"..."Z" | "_"
|
|
|
|
TokIdentifier: ("0"..."9")* `ualpha` (`ualpha` | "0"..."9")*
|
|
|
|
TokVarName: "$" `ualpha` (`ualpha` | "0"..."9")*
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Note that unlike most languages, TableGen allows :token:`TokIdentifier` to
|
|
|
|
begin with a number. In case of ambiguity, a token will be interpreted as a
|
|
|
|
numeric literal rather than an identifier.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen also has two string-like literals:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
TokString: '"' <non-'"' characters and C-like escapes> '"'
|
|
|
|
TokCodeFragment: "[{" <shortest text not containing "}]"> "}]"
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
:token:`TokCodeFragment` is essentially a multiline string literal
|
|
|
|
delimited by ``[{`` and ``}]``.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. note::
|
|
|
|
The current implementation accepts the following C-like escapes::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
\\ \' \" \t \n
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen also has the following keywords::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
bit bits class code dag
|
|
|
|
def foreach defm field in
|
|
|
|
int let list multiclass string
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen also has "bang operators" which have a
|
|
|
|
wide variety of meanings:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
BangOperator: one of
|
|
|
|
:!eq !if !head !tail !con
|
2014-09-03 15:17:03 +02:00
|
|
|
:!add !shl !sra !srl !and
|
2016-11-15 07:49:28 +01:00
|
|
|
:!or !empty !subst !foreach !strconcat
|
2018-03-06 14:49:16 +01:00
|
|
|
:!cast !listconcat !size !foldl
|
2018-03-14 12:00:57 +01:00
|
|
|
:!isa !dag !le !lt !ge
|
|
|
|
:!gt !ne
|
2016-11-15 07:49:28 +01:00
|
|
|
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Syntax
|
|
|
|
======
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen has an ``include`` mechanism. It does not play a role in the
|
|
|
|
syntax per se, since it is lexically replaced with the contents of the
|
|
|
|
included file.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
IncludeDirective: "include" `TokString`
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
TableGen's top-level production consists of "objects".
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
TableGenFile: `Object`*
|
2018-03-09 13:24:42 +01:00
|
|
|
Object: `Class` | `Def` | `Defm` | `Defset` | `Let` | `MultiClass` |
|
|
|
|
`Foreach`
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
``class``\es
|
|
|
|
------------
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
Class: "class" `TokIdentifier` [`TemplateArgList`] `ObjectBody`
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
TemplateArgList: "<" `Declaration` ("," `Declaration`)* ">"
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
A ``class`` declaration creates a record which other records can inherit
|
|
|
|
from. A class can be parametrized by a list of "template arguments", whose
|
|
|
|
values can be used in the class body.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
A given class can only be defined once. A ``class`` declaration is
|
|
|
|
considered to define the class if any of the following is true:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. break ObjectBody into its consituents so that they are present here?
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
#. The :token:`TemplateArgList` is present.
|
|
|
|
#. The :token:`Body` in the :token:`ObjectBody` is present and is not empty.
|
|
|
|
#. The :token:`BaseClassList` in the :token:`ObjectBody` is present.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
You can declare an empty class by giving and empty :token:`TemplateArgList`
|
|
|
|
and an empty :token:`ObjectBody`. This can serve as a restricted form of
|
|
|
|
forward declaration: note that records deriving from the forward-declared
|
|
|
|
class will inherit no fields from it since the record expansion is done
|
|
|
|
when the record is parsed.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
Every class has an implicit template argument called ``NAME``, which is set
|
|
|
|
to the name of the instantiating ``def`` or ``defm``. The result is undefined
|
|
|
|
if the class is instantiated by an anonymous record.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Declarations
|
|
|
|
------------
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. Omitting mention of arcane "field" prefix to discourage its use.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
The declaration syntax is pretty much what you would expect as a C++
|
|
|
|
programmer.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
Declaration: `Type` `TokIdentifier` ["=" `Value`]
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2016-07-02 21:28:40 +02:00
|
|
|
It assigns the value to the identifier.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Types
|
|
|
|
-----
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
Type: "string" | "code" | "bit" | "int" | "dag"
|
|
|
|
:| "bits" "<" `TokInteger` ">"
|
|
|
|
:| "list" "<" `Type` ">"
|
|
|
|
:| `ClassID`
|
|
|
|
ClassID: `TokIdentifier`
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Both ``string`` and ``code`` correspond to the string type; the difference
|
|
|
|
is purely to indicate programmer intention.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
The :token:`ClassID` must identify a class that has been previously
|
|
|
|
declared or defined.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Values
|
|
|
|
------
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
Value: `SimpleValue` `ValueSuffix`*
|
|
|
|
ValueSuffix: "{" `RangeList` "}"
|
|
|
|
:| "[" `RangeList` "]"
|
|
|
|
:| "." `TokIdentifier`
|
|
|
|
RangeList: `RangePiece` ("," `RangePiece`)*
|
|
|
|
RangePiece: `TokInteger`
|
|
|
|
:| `TokInteger` "-" `TokInteger`
|
|
|
|
:| `TokInteger` `TokInteger`
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
The peculiar last form of :token:`RangePiece` is due to the fact that the
|
|
|
|
"``-``" is included in the :token:`TokInteger`, hence ``1-5`` gets lexed as
|
|
|
|
two consecutive :token:`TokInteger`'s, with values ``1`` and ``-5``,
|
|
|
|
instead of "1", "-", and "5".
|
|
|
|
The :token:`RangeList` can be thought of as specifying "list slice" in some
|
|
|
|
contexts.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
:token:`SimpleValue` has a number of forms:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: `TokIdentifier`
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
The value will be the variable referenced by the identifier. It can be one
|
|
|
|
of:
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. The code for this is exceptionally abstruse. These examples are a
|
|
|
|
best-effort attempt.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
* name of a ``def``, such as the use of ``Bar`` in::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
def Bar : SomeClass {
|
|
|
|
int X = 5;
|
|
|
|
}
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
def Foo {
|
|
|
|
SomeClass Baz = Bar;
|
|
|
|
}
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
* value local to a ``def``, such as the use of ``Bar`` in::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
def Foo {
|
|
|
|
int Bar = 5;
|
|
|
|
int Baz = Bar;
|
|
|
|
}
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2018-06-04 16:26:12 +02:00
|
|
|
Values defined in superclasses can be accessed the same way.
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
* a template arg of a ``class``, such as the use of ``Bar`` in::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
class Foo<int Bar> {
|
|
|
|
int Baz = Bar;
|
|
|
|
}
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2018-06-04 16:26:12 +02:00
|
|
|
* value local to a ``class``, such as the use of ``Bar`` in::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2018-06-04 16:26:12 +02:00
|
|
|
class Foo {
|
2014-04-01 11:51:49 +02:00
|
|
|
int Bar = 5;
|
|
|
|
int Baz = Bar;
|
|
|
|
}
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
* a template arg to a ``multiclass``, such as the use of ``Bar`` in::
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
multiclass Foo<int Bar> {
|
2018-06-04 16:26:12 +02:00
|
|
|
def : SomeClass<Bar>;
|
2014-04-01 11:51:49 +02:00
|
|
|
}
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2018-06-04 16:26:12 +02:00
|
|
|
* the iteration variable of a ``foreach``, such as the use of ``i`` in::
|
|
|
|
|
|
|
|
foreach i = 0-5 in
|
|
|
|
def Foo#i;
|
|
|
|
|
|
|
|
* a variable defined by ``defset``
|
|
|
|
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
* the implicit template argument ``NAME`` in a ``class`` or ``multiclass``
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: `TokInteger`
|
|
|
|
|
|
|
|
This represents the numeric value of the integer.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: `TokString`+
|
|
|
|
|
|
|
|
Multiple adjacent string literals are concatenated like in C/C++. The value
|
|
|
|
is the concatenation of the strings.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: `TokCodeFragment`
|
|
|
|
|
|
|
|
The value is the string value of the code fragment.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: "?"
|
|
|
|
|
|
|
|
``?`` represents an "unset" initializer.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: "{" `ValueList` "}"
|
|
|
|
ValueList: [`ValueListNE`]
|
|
|
|
ValueListNE: `Value` ("," `Value`)*
|
|
|
|
|
|
|
|
This represents a sequence of bits, as would be used to initialize a
|
|
|
|
``bits<n>`` field (where ``n`` is the number of bits).
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: `ClassID` "<" `ValueListNE` ">"
|
|
|
|
|
|
|
|
This generates a new anonymous record definition (as would be created by an
|
|
|
|
unnamed ``def`` inheriting from the given class with the given template
|
|
|
|
arguments) and the value is the value of that record definition.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: "[" `ValueList` "]" ["<" `Type` ">"]
|
|
|
|
|
|
|
|
A list initializer. The optional :token:`Type` can be used to indicate a
|
|
|
|
specific element type, otherwise the element type will be deduced from the
|
|
|
|
given values.
|
|
|
|
|
|
|
|
.. The initial `DagArg` of the dag must start with an identifier or
|
|
|
|
!cast, but this is more of an implementation detail and so for now just
|
|
|
|
leave it out.
|
|
|
|
|
|
|
|
.. productionlist::
|
Fix BNF nits in TableGen language reference.
Summary:
In the course of writing an experimental ANTLR grammar based on this
document, I found three errors in the documented BNF:
SimpleValues of dag type are allowed to have no operands at all after
the initial DagArg specifying the operator. For example, the value
(outs) is extremely common in backends; an example in the test suite
is test/TableGen/AsmVariant.td line 30. But the BNF doesn't allow
DagArgList to expand to the empty string (it must contain at least one
DagArg), and therefore the DagArgList specifying the operands in the
dag-shaped production for SimpleValue should be optional.
In the production for BodyItem with a 'let' and an optional RangeList,
the RangeList should have braces around it if it's present, matching
code such as "let E{7-0} = ..." on test/TableGen/BitsInit.td line 42.
Those braces aren't included in the RangeList nonterminal itself, so
instead they need to be part of the optional segment of the BodyItem
production.
Finally, the identifier after 'defm' should be optional. Again, this
is very common in the real back end .td files; an example in the test
suite is in test/TableGen/defmclass.td line 49.
Reviewers: rengolin, nhaehnle, stoklund
Reviewed By: nhaehnle
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45818
llvm-svn: 330570
2018-04-23 11:15:47 +02:00
|
|
|
SimpleValue: "(" `DagArg` [`DagArgList`] ")"
|
2014-04-01 11:51:49 +02:00
|
|
|
DagArgList: `DagArg` ("," `DagArg`)*
|
|
|
|
DagArg: `Value` [":" `TokVarName`] | `TokVarName`
|
|
|
|
|
|
|
|
The initial :token:`DagArg` is called the "operator" of the dag.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
SimpleValue: `BangOperator` ["<" `Type` ">"] "(" `ValueListNE` ")"
|
|
|
|
|
|
|
|
Bodies
|
|
|
|
------
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
ObjectBody: `BaseClassList` `Body`
|
|
|
|
BaseClassList: [":" `BaseClassListNE`]
|
|
|
|
BaseClassListNE: `SubClassRef` ("," `SubClassRef`)*
|
|
|
|
SubClassRef: (`ClassID` | `MultiClassID`) ["<" `ValueList` ">"]
|
|
|
|
DefmID: `TokIdentifier`
|
|
|
|
|
|
|
|
The version with the :token:`MultiClassID` is only valid in the
|
|
|
|
:token:`BaseClassList` of a ``defm``.
|
|
|
|
The :token:`MultiClassID` should be the name of a ``multiclass``.
|
|
|
|
|
|
|
|
.. put this somewhere else
|
|
|
|
|
|
|
|
It is after parsing the base class list that the "let stack" is applied.
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
Body: ";" | "{" BodyList "}"
|
|
|
|
BodyList: BodyItem*
|
|
|
|
BodyItem: `Declaration` ";"
|
Fix BNF nits in TableGen language reference.
Summary:
In the course of writing an experimental ANTLR grammar based on this
document, I found three errors in the documented BNF:
SimpleValues of dag type are allowed to have no operands at all after
the initial DagArg specifying the operator. For example, the value
(outs) is extremely common in backends; an example in the test suite
is test/TableGen/AsmVariant.td line 30. But the BNF doesn't allow
DagArgList to expand to the empty string (it must contain at least one
DagArg), and therefore the DagArgList specifying the operands in the
dag-shaped production for SimpleValue should be optional.
In the production for BodyItem with a 'let' and an optional RangeList,
the RangeList should have braces around it if it's present, matching
code such as "let E{7-0} = ..." on test/TableGen/BitsInit.td line 42.
Those braces aren't included in the RangeList nonterminal itself, so
instead they need to be part of the optional segment of the BodyItem
production.
Finally, the identifier after 'defm' should be optional. Again, this
is very common in the real back end .td files; an example in the test
suite is in test/TableGen/defmclass.td line 49.
Reviewers: rengolin, nhaehnle, stoklund
Reviewed By: nhaehnle
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45818
llvm-svn: 330570
2018-04-23 11:15:47 +02:00
|
|
|
:| "let" `TokIdentifier` [ "{" `RangeList` "}" ] "=" `Value` ";"
|
2014-04-01 11:51:49 +02:00
|
|
|
|
|
|
|
The ``let`` form allows overriding the value of an inherited field.
|
|
|
|
|
|
|
|
``def``
|
|
|
|
-------
|
|
|
|
|
|
|
|
.. productionlist::
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
Def: "def" [`Value`] `ObjectBody`
|
|
|
|
|
|
|
|
Defines a record whose name is given by the optional :token:`Value`. The value
|
|
|
|
is parsed in a special mode where global identifiers (records and variables
|
|
|
|
defined by ``defset``) are not recognized, and all unrecognized identifiers
|
|
|
|
are interpreted as strings.
|
2014-04-01 11:51:49 +02:00
|
|
|
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
If no name is given, the record is anonymous. The final name of anonymous
|
|
|
|
records is undefined, but globally unique.
|
2014-04-01 11:51:49 +02:00
|
|
|
|
|
|
|
Special handling occurs if this ``def`` appears inside a ``multiclass`` or
|
|
|
|
a ``foreach``.
|
|
|
|
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
When a non-anonymous record is defined in a multiclass and the given name
|
|
|
|
does not contain a reference to the implicit template argument ``NAME``, such
|
|
|
|
a reference will automatically be prepended. That is, the following are
|
|
|
|
equivalent inside a multiclass::
|
|
|
|
|
|
|
|
def Foo;
|
|
|
|
def NAME#Foo;
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
``defm``
|
|
|
|
--------
|
|
|
|
|
|
|
|
.. productionlist::
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
Defm: "defm" [`Value`] ":" `BaseClassListNE` ";"
|
|
|
|
|
|
|
|
The :token:`BaseClassList` is a list of at least one ``multiclass`` and any
|
|
|
|
number of ``class``'s. The ``multiclass``'s must occur before any ``class``'s.
|
|
|
|
|
|
|
|
Instantiates all records defined in all given ``multiclass``'s and adds the
|
|
|
|
given ``class``'s as superclasses.
|
|
|
|
|
|
|
|
The name is parsed in the same special mode used by ``def``. If the name is
|
|
|
|
missing, a globally unique string is used instead (but instantiated records
|
|
|
|
are not considered to be anonymous, unless they were originally defined by an
|
|
|
|
anonymous ``def``) That is, the following have different semantics::
|
|
|
|
|
|
|
|
defm : SomeMultiClass<...>; // some globally unique name
|
|
|
|
defm "" : SomeMultiClass<...>; // empty name string
|
|
|
|
|
|
|
|
When it occurs inside a multiclass, the second variant is equivalent to
|
|
|
|
``defm NAME : ...``. More generally, when ``defm`` occurs in a multiclass and
|
|
|
|
its name does not contain a reference to the implicit template argument
|
|
|
|
``NAME``, such a reference will automatically be prepended. That is, the
|
|
|
|
following are equivalent inside a multiclass::
|
2014-04-01 11:51:49 +02:00
|
|
|
|
TableGen: Streamline the semantics of NAME
Summary:
The new rules are straightforward. The main rules to keep in mind
are:
1. NAME is an implicit template argument of class and multiclass,
and will be substituted by the name of the instantiating def/defm.
2. The name of a def/defm in a multiclass must contain a reference
to NAME. If such a reference is not present, it is automatically
prepended.
And for some additional subtleties, consider these:
3. defm with no name generates a unique name but has no special
behavior otherwise.
4. def with no name generates an anonymous record, whose name is
unique but undefined. In particular, the name won't contain a
reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers when you pushed them to their limits, as the old
version of the TableGen test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the details of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm, javed.absar
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D47430
llvm-svn: 333900
2018-06-04 16:26:05 +02:00
|
|
|
defm Foo : SomeMultiClass<...>;
|
|
|
|
defm NAME#Foo : SomeMultiClass<...>;
|
2014-04-01 11:51:49 +02:00
|
|
|
|
2018-03-09 13:24:42 +01:00
|
|
|
``defset``
|
|
|
|
----------
|
|
|
|
.. productionlist::
|
|
|
|
Defset: "defset" `Type` `TokIdentifier` "=" "{" `Object`* "}"
|
|
|
|
|
|
|
|
All records defined inside the braces via ``def`` and ``defm`` are collected
|
|
|
|
in a globally accessible list of the given name (in addition to being added
|
|
|
|
to the global collection of records as usual). Anonymous records created inside
|
|
|
|
initializier expressions using the ``Class<args...>`` syntax are never collected
|
|
|
|
in a defset.
|
|
|
|
|
|
|
|
The given type must be ``list<A>``, where ``A`` is some class. It is an error
|
|
|
|
to define a record (via ``def`` or ``defm``) inside the braces which doesn't
|
|
|
|
derive from ``A``.
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
``foreach``
|
|
|
|
-----------
|
|
|
|
|
|
|
|
.. productionlist::
|
2018-03-09 13:24:30 +01:00
|
|
|
Foreach: "foreach" `ForeachDeclaration` "in" "{" `Object`* "}"
|
|
|
|
:| "foreach" `ForeachDeclaration` "in" `Object`
|
|
|
|
ForeachDeclaration: ID "=" ( "{" `RangeList` "}" | `RangePiece` | `Value` )
|
2014-04-01 11:51:49 +02:00
|
|
|
|
|
|
|
The value assigned to the variable in the declaration is iterated over and
|
|
|
|
the object or object list is reevaluated with the variable set at each
|
|
|
|
iterated value.
|
|
|
|
|
2018-03-09 13:24:30 +01:00
|
|
|
Note that the productions involving RangeList and RangePiece have precedence
|
|
|
|
over the more generic value parsing based on the first token.
|
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
Top-Level ``let``
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
.. productionlist::
|
|
|
|
Let: "let" `LetList` "in" "{" `Object`* "}"
|
|
|
|
:| "let" `LetList` "in" `Object`
|
|
|
|
LetList: `LetItem` ("," `LetItem`)*
|
|
|
|
LetItem: `TokIdentifier` [`RangeList`] "=" `Value`
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
This is effectively equivalent to ``let`` inside the body of a record
|
|
|
|
except that it applies to multiple records at a time. The bindings are
|
|
|
|
applied at the end of parsing the base classes of a record.
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
``multiclass``
|
|
|
|
--------------
|
2013-01-07 03:43:44 +01:00
|
|
|
|
2014-04-01 11:51:49 +02:00
|
|
|
.. productionlist::
|
|
|
|
MultiClass: "multiclass" `TokIdentifier` [`TemplateArgList`]
|
|
|
|
: [":" `BaseMultiClassList`] "{" `MultiClassObject`+ "}"
|
|
|
|
BaseMultiClassList: `MultiClassID` ("," `MultiClassID`)*
|
|
|
|
MultiClassID: `TokIdentifier`
|
|
|
|
MultiClassObject: `Def` | `Defm` | `Let` | `Foreach`
|