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
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
