summaryrefslogtreecommitdiffstats
path: root/llvm/test/TableGen/Dag.td
Commit message (Collapse)AuthorAgeFilesLines
* TableGen: Streamline the semantics of NAMENicolai Haehnle2018-06-041-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Mark 36 tests as XFAIL:vg_leak in llvm/test/TableGen.NAKAMURA Takumi2013-11-101-0/+1
| | | | | | | In historical reason, tblgen is not strictly required to be free from memory leaks. For now, I mark them as XFAIL, they could be fixed, though. llvm-svn: 194353
* Allow TableGen DAG arguments to be just a name.Jakob Stoklund Olesen2013-03-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* llvm/test/TableGen: Remove XFAIL:vg_leak in dozen of tests, according to ↵NAKAMURA Takumi2012-12-111-1/+0
| | | | | | llvm-x86_64-linux-vg_leak. llvm-svn: 169862
* Add NAME MemberDavid Greene2011-10-191-0/+2
| | | | | | | | Add a Value named "NAME" to each Record. This will be set to the def or defm name when instantiating multiclasses. This will replace the #NAME# processing hack once paste functionality is in place. llvm-svn: 142518
* s/tblgen/llvm-tblgen/g in a few missed places, including the testsPeter Collingbourne2011-10-061-1/+1
| | | | llvm-svn: 141294
* Generalize tblgen's dag parsing logic to handle arbitrary expressionsChris Lattner2010-10-061-0/+36
| | | | | | | | | | | | | | as the operator of the dag. Specifically, this allows parsing things like (F.x 4) in addition to just (a 4). Unfortunately, this runs afoul of an idiom being used by llvmc. It is using dags like (foo [1,2,3]) to represent a list of stuff being passed into foo. With this change, this is parsed as a [1,2,3] subscript on foo instead of being the first argument to the dag. Cope with this in the short term by requiring a "-llvmc-temp-hack" argument to tblgen to get the old parsing behavior. llvm-svn: 115742
* rename add some comments.Chris Lattner2010-10-061-0/+35
llvm-svn: 115741
OpenPOWER on IntegriCloud