summaryrefslogtreecommitdiffstats
path: root/llvm/docs/TableGen/LangRef.rst
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Introduce an if/then/else statement.Simon Tatham2020-01-141-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows you to make some of the defs in a multiclass or `foreach` conditional on an expression computed from the parameters or iteration variables. It was already possible to simulate an if statement using a `foreach` with a dummy iteration variable and a list constructed using `!if` so that it had length 0 or 1 depending on the condition, e.g. foreach unusedIterationVar = !if(condition, [1], []<int>) in { ... } But this syntax is nicer to read, and also more convenient because it allows an else clause. To avoid upheaval in the implementation, I've implemented `if` as pure syntactic sugar on the `foreach` implementation: internally, `ParseIf` actually does construct exactly the kind of foreach shown above (and another reversed one for the else clause if present). Reviewers: nhaehnle, hfinkel Reviewed By: hfinkel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71474
* [TableGen] Introduce a `defvar` statement.Simon Tatham2020-01-141-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows you to define a global or local variable to an arbitrary value, and refer to it in subsequent definitions. The main use I anticipate for this is if you have to compute some difficult function of the parameters of a multiclass, and then use it many times. For example: multiclass Foo<int i, string s> { defvar op = !cast<BaseClass>("whatnot_" # s # "_" # i); def myRecord { dag a = (op this, (op that, the other), (op x, y, z)); int b = op.subfield; } def myOtherRecord<"template params including", op>; } There are a couple of ways to do this already, but they're not really satisfactory. You can replace `defvar x = y` with a loop over a singleton list, `foreach x = [y] in { ... }` - but that's unintuitive to someone who hasn't seen that workaround idiom before, and requires an extra pair of braces that you often didn't really want. Or you can define a nested pair of multiclasses, with the inner one taking `x` as a template parameter, and the outer one instantiating it just once with the desired value of `x` computed from its other parameters - but that makes it awkward to sequentially compute each value based on the previous ones. I think `defvar` makes things considerably easier. You can also use `defvar` at the top level, where it inserts globals into the same map used by `defset`. That allows you to define global constants without having to make a dummy record for them to live in: defvar MAX_BUFSIZE = 512; // previously: // def Dummy { int MAX_BUFSIZE = 512; } // and then refer to Dummy.MAX_BUFSIZE everywhere Reviewers: nhaehnle, hfinkel Reviewed By: hfinkel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71407
* [TableGen] Add bang-operators !getop and !setop.Simon Tatham2019-12-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: These allow you to get and set the operator of a dag node, without affecting its list of arguments. `!getop` is slightly fiddly because in many contexts you need its return value to have a static type more specific than 'any record'. It works to say `!cast<BaseClass>(!getop(...))`, but it's cumbersome, so I made `!getop` take an optional type suffix itself, so that can be written as the shorter `!getop<BaseClass>(...)`. Reviewers: hfinkel, nhaehnle Reviewed By: nhaehnle Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71191
* [docs] Fix TableGen/LangRef typosJordan Rupprecht2019-06-131-2/+2
| | | | | | | | This fixes: - `Pred` -> `Prep` - `IfDef` -> `Ifdef` (rst is case sensitive here) llvm-svn: 363294
* [TableGen] Introduce !listsplat 'binary' operatorRoman Lebedev2019-04-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: ``` ``!listsplat(a, size)`` A list value that contains the value ``a`` ``size`` times. Example: ``!listsplat(0, 2)`` results in ``[0, 0]``. ``` I plan to use this in X86ScheduleBdVer2.td for LoadRes handling. This is a little bit controversial because unlike every other binary operator the types aren't identical. Reviewers: stoklund, javed.absar, nhaehnle, craig.topper Reviewed By: javed.absar Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60367 llvm-svn: 358117
* [Tablegen] Add support for the !mul operator.Nicola Zaghen2019-03-011-1/+1
| | | | | | | | | This is a small addition to arithmetic operations that improves expressiveness of the language. Differential Revision: https://reviews.llvm.org/D58775 llvm-svn: 355187
* [TblGen] Extend !if semantics through new feature !condJaved Absar2019-01-251-1/+9
| | | | | | | | | | | | | | | | | This patch extends TableGen language with !cond operator. Instead of embedding !if inside !if which can get cumbersome, one can now use !cond. Below is an example to convert an integer 'x' into a string: !cond(!lt(x,0) : "Negative", !eq(x,0) : "Zero", !eq(x,1) : "One, 1 : "MoreThanOne") Reviewed By: hfinkel, simon_tatham, greened Differential Revision: https://reviews.llvm.org/D55758 llvm-svn: 352185
* [TableGen] Preprocessing supportVyacheslav Zakharin2018-11-271-1/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D54926 llvm-svn: 347686
* Reverted r347092 due to the following build fails:Vyacheslav Zakharin2018-11-171-48/+1
| | | | | | | http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/8662 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26263 llvm-svn: 347129
* Preprocessing support in tablegen.Vyacheslav Zakharin2018-11-161-1/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D53840 llvm-svn: 347092
* TableGen: some LangRef doc fixesNicolai Haehnle2018-06-041-3/+12
| | | | | | | | | | | | | Summary: Change-Id: I1442e2daa09cab727a01d8c31893b50e644a5cd3 Reviewers: tra, simon_tatham, craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47530 Change-Id: I397655dd18b7ff978c1affa3174740d9c1a82594 llvm-svn: 333901
* TableGen: Streamline the semantics of NAMENicolai Haehnle2018-06-041-16/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix BNF nits in TableGen language reference.Simon Tatham2018-04-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* TableGen: Add !ne, !le, !lt, !ge, and !gt comparisonsNicolai Haehnle2018-03-141-1/+2
| | | | | | | | Change-Id: I8e2ece677268972d578a787467f7ef52a1f33a71 Differential revision: https://reviews.llvm.org/D44114 llvm-svn: 327496
* TableGen: Add !dag function for constructionNicolai Haehnle2018-03-141-1/+1
| | | | | | | | | | | | | | | 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
* TableGen: Add a defset statementNicolai Haehnle2018-03-091-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | 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
* TableGen: Allow arbitrary list values as ranges of foreachNicolai Haehnle2018-03-091-2/+6
| | | | | | | | | 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
* TableGen: add !isa operationNicolai Haehnle2018-03-091-0/+1
| | | | | | | | Change-Id: Iddb724c3ae706d82933a2d82c91d07e0e36b30e3 Differential revision: https://reviews.llvm.org/D44105 llvm-svn: 327117
* TableGen: Add !foldl operationNicolai Haehnle2018-03-061-1/+1
| | | | | Change-Id: I63d67bf6e0b315e2d3360e47e3b62c9517f38987 llvm-svn: 326790
* TableGen: Add !size operationNicolai Haehnle2018-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* TableGen: Add operator !orMatt Arsenault2016-11-151-1/+3
| | | | llvm-svn: 286936
* fix some various typos in the docSylvestre Ledru2016-07-021-1/+1
| | | | llvm-svn: 274449
* Rename all references to old mailing lists to new lists.llvm.org address.Tanya Lattner2015-08-051-1/+1
| | | | llvm-svn: 243999
* Document !and. Fix !shl and friends -- they provide binary operations.Joerg Sonnenberger2014-09-031-1/+1
| | | | llvm-svn: 217034
* Update Tablegen documents given that binary literals are now sizedPete Cooper2014-08-071-0/+4
| | | | llvm-svn: 215088
* [tablegen] Add !listconcat operator with the similar semantics as !strconcatDaniel Sanders2014-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* [docs] VCS contains a record of authorshipSean Silva2014-04-081-2/+0
| | | | | | No need to explicitly mention the author in the document. llvm-svn: 205793
* [docs] Fix some linksSean Silva2014-04-071-1/+1
| | | | | | | | The TableGen docs have changed structure Patch by Tay Ray Chuan! llvm-svn: 205744
* Recover TableGen/LangRef, make it officialRenato Golin2014-04-011-515/+299
| | | | | | | | | | | | | 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
* Re-factor TableGen docsRenato Golin2014-03-201-299/+515
| | | | | | | | | | | | | 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
* [docs] TableGen easter egg: Multiline string literalsSean Silva2014-02-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Allow TableGen DAG arguments to be just a name.Jakob Stoklund Olesen2013-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [docs] Fixup fallout from other grammar fixup.Sean Silva2013-02-011-1/+1
| | | | | | | | | | | | 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
* [docs] Add missing colon to TableGen grammar.Sean Silva2013-02-011-1/+1
| | | | | | Spotted by Eli Bendersky. llvm-svn: 174143
* Add an addition operator to TableGenHal Finkel2013-01-251-1/+1
| | | | | | | This adds an !add(a, b) operator to tablegen; this will be used to cleanup the PPC register definitions. llvm-svn: 173445
* TableGen/LangRef: link bang operators into the productionlistSean Silva2013-01-091-4/+6
| | | | | | | | Now BangOperator should be nicely hyperlinked. Pointed out by Joel Jones. llvm-svn: 171942
* TableGen/LangRef: discuss specific C-like escapesSean Silva2013-01-091-0/+5
| | | | | | Suggested by Joel Jones. llvm-svn: 171941
* docs: Fix mention of DefmID to MultiClassID.Sean Silva2013-01-091-3/+3
| | | | llvm-svn: 171940
* docs: Bring TableGen syntax a bit closer to reality.Sean Silva2013-01-091-1/+2
| | | | | | | | | It's not just def's but actually a limited subset of Object's that are allowed inside a multiclass. Spotted by Joel Jones. llvm-svn: 171935
* tblgen, docs: Add initial syntax reference.Sean Silva2013-01-071-0/+375
llvm-svn: 171685
OpenPOWER on IntegriCloud