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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207865 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205289 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204351 91177308-0d34-0410-b5e6-96231b3b80d8
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
}]>;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201033 91177308-0d34-0410-b5e6-96231b3b80d8
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)>;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177843 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174144 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an !add(a, b) operator to tablegen; this will be used
to cleanup the PPC register definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173445 91177308-0d34-0410-b5e6-96231b3b80d8
It's not just def's but actually a limited subset of Object's that are
allowed inside a multiclass.
Spotted by Joel Jones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171935 91177308-0d34-0410-b5e6-96231b3b80d8
