The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
Summary:
This is essentially a rewrite of the backend which introduces TableGen
base classes GenericEnum, GenericTable, and SearchIndex. They allow
generating custom enums and tables with lookup functions using
separately defined records as the underlying database.
Also added as part of this change:
- Lookup functions may use indices composed of multiple fields.
- Instruction fields are supported similar to Intrinsic fields.
- When the lookup key has contiguous numeric values, the lookup
function will directly index into the table instead of using a binary
search.
The existing SearchableTable functionality is internally mapped to the
new primitives.
Change-Id: I444f3490fa1dbfb262d7286a1660a2c4308e9932
Reviewers: arsenm, tra, t.p.northover
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D48013
llvm-svn: 335225
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
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
Should be a harmless trimming of trailing whitespace from a
documentation file.
(There are other instances of trailing whitespace in this file alone.
I've only fixed one of them, on the basis that that way the rest are
still available for other people's commit-access tests :-)
llvm-svn: 330567
Summary:
Cast-from-string for records isn't going away, but cast-from-string for
variables is a pretty dodgy feature to have, especially when referencing
template arguments. It's doubtful that this ever worked in a reliable
way, and nobody seems to be using it, so let's get rid of it and get
some related cleanups.
Change-Id: I395ac8a43fef4cf98e611f2f552300d21e99b66a
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44195
llvm-svn: 327844
Additionally, allow more than two operands to !con, !add, !and, !or
in the same way as is already allowed for !listconcat and !strconcat.
Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93
Differential revision: https://reviews.llvm.org/D44112
llvm-svn: 327494
This makes using !dag more convenient in some cases.
Change-Id: I0a8c35e15ccd1ecec778fd1c8d64eee38d74517c
Differential revision: https://reviews.llvm.org/D44111
llvm-svn: 327493
This allows constructing DAG nodes with programmatically determined
names, and can simplify constructing DAG nodes in other cases as
well.
Also, add documentation and some very simple tests for the already
existing !con.
Change-Id: Ida61cd82e99752548d7109ce8da34d29da56a5f7
Differential revision: https://reviews.llvm.org/D44110
llvm-svn: 327492
Allows capturing a list of concrete instantiated defs.
This can be combined with foreach to create parallel sets of def
instantiations with less repetition in the source. This purpose is
largely also served by multiclasses, but in some cases multiclasses
can't be used.
The motivating example for this change is having a large set of
intrinsics, which are generated from the IntrinsicsBackend.td file
included by Intrinsics.td, and a corresponding set of instruction
selection patterns, which are generated via the backend's .td files.
Multiclasses cannot be used to eliminate the redundancy in this case,
because a multiclass cannot span both LLVM's common .td files and
the backend .td files at the same time.
Change-Id: I879e35042dceea542a5e6776fad23c5e0e69e76b
Differential revision: https://reviews.llvm.org/D44109
llvm-svn: 327121
The changes to FieldInit are required to make field references (Def.field)
work inside a ForeachDeclaration: previously, Def.field wasn't resolved
immediately when Def was already a fully resolved DefInit.
Change-Id: I9875baec2fc5aac8c2b249e45b9cf18c65ae699b
llvm-svn: 327120
Summary:
Distinguish two relationships between types: is-a and convertible-to.
For example, a bit is not an int or vice versa, but they can be
converted into each other (with range checks that you can think of
as "dynamic": unlike other type checks, those range checks do not
happen during parsing, but only once the final values have been
established).
Actually converting initializers between types is subtle: even
when values of type A can be converted to type B (e.g. int into
string), it may not be possible to do so with a concrete initializer
(e.g., a VarInit that refers to a variable of type int cannot
be immediately converted to a string).
For this reason, distinguish between getCastTo and convertInitializerTo:
the latter implements the actual conversion when appropriate, while
the former will first try to do the actual conversion and fall back
to introducing a !cast operation so that the conversion will be
delayed until variable references have been resolved.
To make the approach of adding !cast operations to work, !cast needs
to fallback to convertInitializerTo when the special string <-> record
logic does not apply.
This enables casting records to a subclass, although that new
functionality is only truly useful together with !isa, which will be
added in a later change.
The test is removed because it uses !srl on a bit sequence,
which cannot really be supported consistently, but luckily
isn't used anywhere either.
Change-Id: I98168bf52649176654ed2ec61a29bdb29970cfe7
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43753
llvm-svn: 326785
Summary:
This changes the syntax of !foreach so that the first "parameter" is
a new syntactic variable: !foreach(x, lst, expr) will define the
variable x within the scope of expr, and evaluation of the !foreach
will substitute elements of the given list (or dag) for x in expr.
Aside from leading to a nicer syntax, this allows more complex
expressions where x is deeply nested, or even constant expressions
in which x does not occur at all.
!foreach is currently not actually used anywhere in trunk, but I
plan to use it in the AMDGPU backend. If out-of-tree targets are
using it, they can adjust to the new syntax very easily.
Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits, tpr
Differential Revision: https://reviews.llvm.org/D43651
llvm-svn: 326705
Summary:
Returns the size of a list. I have found this to be rather useful in some
development for the AMDGPU backend where we could simplify our .td files
by concatenating list<LLVMType> for complex intrinsics. Doing so requires
us to compute the position argument for LLVMMatchType.
Basically, the usage is in a pattern that looks somewhat like this:
list<LLVMType> argtypes =
!listconcat(base,
[llvm_any_ty, LLVMMatchType<!size(base)>]);
Change-Id: I360a0b000fd488d18bea412228230fd93722bd2c
Reviewers: arsenm, craig.topper, tra, MartinO
Subscribers: wdng, llvm-commits, tpr
Differential Revision: https://reviews.llvm.org/D43553
llvm-svn: 325883
Document the 'code' data type, and that value{15-17} is different to
value{17-15}.
Patch by @chenwj (Wei-Ren Chen).
Differential Revision: https://reviews.llvm.org/D32117
llvm-svn: 301920
X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible.
It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals.
This TableGen backend replaces the tables by automatically generating them.
Differential Revision: https://reviews.llvm.org/D30451
llvm-svn: 297127
Lots of blocks had "llvm" or "nasm" syntax types but either weren't following
the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type
doesn't even exist (nasm?).
Other documents had :options: what were invalid. I only removed those that had
warnings, and left the ones that didn't, in order to follow the principle of
least surprise.
This is like this for ages, but the buildbot is now failing on errors. It may
take a while to upgrade the buildbot's sphinx, if that's even possible, but
that shouldn't stop us from getting docs updates (which seem down for quite
a while).
Also, we're not losing any syntax highlight, since when it doesn't parse, it
doesn't colour. Ie. those blocks are not being highlighted anyway.
I'm trying to get all docs in one go, so that it's easy to revert later if we
do fix, or at least easy to know what's to fix.
llvm-svn: 276109
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 215154
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
llvm-svn: 215111
Convert the operand to int if possible, i.e. if the value is properly
initialized. (I suppose there is further room for improvement here to also
peform the shift if the uninitialized bits are shifted out.)
With this little change we can now compute the scaling factor for compressed
displacement with pure tablegen code in the X86 backend. This is useful
because both the X86-disassembler-specific part of tablegen and the assembler
need this and TD is the natural sharing place.
The patch also adds the missing documentation for the shift and add operator.
llvm-svn: 213277
Summary:
It concatenates two or more lists. In addition to the !strconcat semantics
the lists must have the same element type.
My overall aim is to make it easy to append to Instruction.Predicates
rather than override it. This can be done by concatenating lists passed as
arguments, or by concatenating lists passed in additional fields.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D3506
llvm-svn: 208183
Summary:
* Updated the documentation
* Added a test for >2 arguments
* Added a check for the lexical concatenation
* Made the existing test a bit stricter.
Reviewers: t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D3485
llvm-svn: 207865
Making the new TableGen documentation official and marking the old file as
"Moved". Also, reverting the original LangRef as the normative formal
description of the language, while keeping the "new" LangRef as LangIntro
for the less inlcined to reading language grammars.
We should remove TableGenFundamentals.rst one day, but for now, just a
warning that it moved will have to do, while we make sure there are no more
links to it from elsewhere.
llvm-svn: 205289
This is mainly a movement of content around to give place to new content
allowing different people to add bits to it in the right place. There is some
new content, but mostly to fill the gaps left by text movement.
I'm dropping the old syntax documentation as it has the problem of being
quickly outdated by changes and largely unnecessary to people not involved
in creating the language, but using it, which is the whole point of the
documentation.
llvm-svn: 204351
They're called code fragments, but they are really multiline string
literals. Just spotted this usage in a patch by Aaron using "code
fragments" for holding documentation text. I remember someone bemoaning
the lack of multiline string literals in TableGen, so I'm explicitly
documenting that code fragments are multiline string literals.
Let it be known that any use case needing multiline string literals in
TableGen (such as descriptions of options, or whatnot) can use use
code fragments (instead of C-style string concatenation or exceedingly
long lines). E.g.
class Bar<int n>;
class Baz<int n>;
class Doc<string desc> {
string Desc = desc;
}
def Foo : Bar<1>, Baz<3>, Doc<[{
This Foo is a Bar, and also a Baz. It can take 3 values:
* Qux
* Quux
* Quuux
}]>;
llvm-svn: 201033
DAG arguments can optionally be named:
(dag node, node:$name)
With this change, the node is also optional:
(dag node, node:$name, $name)
The missing node is treated as an UnsetInit, so the above is equivalent
to:
(dag node, node:$name, ?:$name)
This syntax is useful in output patterns where we currently require the
types of variables to be repeated:
def : Pat<(subc i32:$b, i32:$c), (SUBCCrr i32:$b, i32:$c)>;
This is preferable:
def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;
llvm-svn: 177843
My "excuse" for not refactoring the grammar here is to not diverge too
far from the grammar in the comments of TGParser.cpp, since I'm not
taking on the quest of majorly refactoring TGParser.cpp at the moment.
One benefit of doing this is that Ideas for refactoring and clarifying
the grammar in this document should translate almost immediately to
beneficial refactorings that can be made to TGParser.cpp.
llvm-svn: 174144
Simon Tatham