summaryrefslogtreecommitdiffstats
path: root/llvm/lib/TableGen/TGParser.h
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Introduce an if/then/else statement.Simon Tatham2020-01-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Remove the error for duplicate include files.River Riddle2019-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This error was originally added a while(7 years) ago when including multiple files was basically always an error. Tablegen now has preprocessor support, which allows for building nice c/c++ style include guards. With the current error being reported, we unfortunately need to double guard when including files: * In user of MyFile.td #ifndef MYFILE_TD include MyFile.td #endif * In MyFile.td #ifndef MYFILE_TD #define MYFILE_TD ... #endif Differential Revision: https://reviews.llvm.org/D70410
* TableGen - fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-101-1/+1
|
* Fix shadow variable warning with llvm::SrcMgr. NFCI.Simon Pilgrim2019-11-091-2/+2
|
* TableGen: Handle nontrivial foreach range boundsMatt Arsenault2019-05-221-1/+2
| | | | | | | | | | | | This allows using anything that isn't a literal integer as the bounds for a foreach. Some of the diagnostics aren't perfect, but nobody ever accused tablegen of having good errors. For example, the existing wording suggests a bitrange is valid, but as far as I can tell this has never worked. Fixes bug 41958. llvm-svn: 361434
* [TblGen] Extend !if semantics through new feature !condJaved Absar2019-01-251-0/+1
| | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [TableGen] Preprocessing supportVyacheslav Zakharin2018-11-271-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D54926 llvm-svn: 347686
* Reverted r347092 due to the following build fails:Vyacheslav Zakharin2018-11-171-3/+2
| | | | | | | 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-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D53840 llvm-svn: 347092
* TableGen: Allow foreach in multiclass to depend on template argsNicolai Haehnle2018-06-211-19/+43
| | | | | | | | | | | | | | | | | | | | Summary: This also allows inner foreach loops to have a list that depends on the iteration variable of an outer foreach loop. The test cases show some very simple examples of how this can be used. This was perhaps the last remaining major non-orthogonality in the TableGen frontend. Change-Id: I79b92d41a5c0e7c03cc8af4000c5e1bda5ef464d Reviewers: tra, simon_tatham, craig.topper, MartinO, arsenm Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D47431 llvm-svn: 335221
* TableGen: Streamline the semantics of NAMENicolai Haehnle2018-06-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* TableGen: Streamline how defs are instantiatedNicolai Haehnle2018-03-211-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instantiating def's and defm's needs to perform the following steps: - for defm's, clone multiclass def prototypes and subsitute template args - for def's and defm's, add subclass definitions, substituting template args - clone the record based on foreach loops and substitute loop iteration variables - override record variables based on the global 'let' stack - resolve the record name (this should be simple, but unfortunately it's not due to existing .td files relying on rather silly implementation details) - for def(m)s in multiclasses, add the unresolved record as a multiclass prototype - for top-level def(m)s, resolve all internal variable references and add them to the record keeper and any active defsets This change streamlines how we go through these steps, by having both def's and defm's feed into a single addDef() method that handles foreach, final resolve, and routing the record to the right place. This happens to make foreach inside of multiclasses work, as the new test case demonstrates. Previously, foreach inside multiclasses was not forbidden by the parser, but it was de facto broken. Another side effect is that the order of "instantiated from" notes in error messages is reversed, as the modified test case shows. This is arguably clearer, since the initial error message ends up pointing directly to whatever triggered the error, and subsequent notes will point to increasingly outer layers of multiclasses. This is consistent with how C++ compilers report nested #includes and nested template instantiations. Change-Id: Ica146d0db2bc133dd7ed88054371becf24320447 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44478 llvm-svn: 328117
* TableGen: Add a defset statementNicolai Haehnle2018-03-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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: Remove unused ParseForeachModeNicolai Haehnle2018-03-091-1/+0
| | | | | | | | | | | | | | | Use the default ParseValueMode instead of ParseForeachMode when parsing the rule ForeachDeclaration ::= ID '=' '[' ValueList ']' because the only difference between the two is how an open brace '{' is handled at the end. In the context of foreach, the 'in' keyword will appear after the ForeachDeclaration, so this special handling of '{' is not required. Change-Id: I4d86bb73bab9ec26752e1273e5213df77cf28d1d llvm-svn: 327119
* TableGen: Move getNewAnonymousName into RecordKeeperNicolai Haehnle2018-03-061-5/+1
| | | | | | | | | | | | | | | | Summary: So that we will be able to generate new anonymous names more easily outside the parser as well. Change-Id: I28f396a7bdbc3ff0c665d466abbd3d31376e21b4 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43755 llvm-svn: 326787
* [TableGen] Remove RecordVal constructor that takes a StringRef and ↵Craig Topper2017-06-011-1/+1
| | | | | | | | Record::setName(StringRef). Leave just the versions that take an Init. They weren't used often enough to justify having two different interfaces. Push the responsiblity of creating a StringInit up to the caller. llvm-svn: 304388
* TableGen: Some more std::string->StringInit* replacementsMatthias Braun2016-12-051-9/+3
| | | | llvm-svn: 288653
* TableGen/TGParser: Prefer SmallVector/ArrayRef over std::vectorMatthias Braun2016-12-051-12/+11
| | | | llvm-svn: 288649
* TableGen/Record: Replace std::vector with SmallVector/ArrayRefMatthias Braun2016-12-051-1/+3
| | | | llvm-svn: 288648
* TableGen: Use StringInit instead of std::string for DagInit arg namesMatthias Braun2016-12-051-1/+1
| | | | llvm-svn: 288644
* TableGen: Use StringRef instead of const std::string& for parametersMatthias Braun2016-12-041-4/+3
| | | | | | | | This avoid an extra construction of a std::string (and a heap allocation) when the caller only has a StringRef but no std::string at hand. llvm-svn: 288610
* [TableGen] Change TGParser::SetValue to take an ArrayRef instead of ↵Craig Topper2016-01-041-2/+2
| | | | | | std::vector reference. Use None in many places where a default constructed vector was being passed. NFC llvm-svn: 256726
* [TableGen] Fix a bug that caused the wrong name for a record built from a ↵Craig Topper2016-01-041-3/+6
| | | | | | | | | | | | multiclass containing a defm called NAME that references another multiclass that contains a defm that uses NAME concatenated with other strings. It would end up doing the concatenations from the second multiclass twice. This occured because SetValue detected a self assignment when trying to set the value of NAME to a VarInit called NAME. NAME is special here and it will get cleaned up later. So add a flag to suppress the self assignment check for this case. Strangely the self-assignment error was returning false indicating it wasn't an error, but it wasn't doing the right thing. So this also changes it to report an error. This fixes the names of some AVX512 FMA instructions that showed this double expansion. llvm-svn: 256725
* [TblGen] ArrayRefize TGParser. No functional change intended.Benjamin Kramer2015-10-241-10/+6
| | | | llvm-svn: 251186
* [TableGen] Resolve complex def names inside multiclassesHal Finkel2015-05-211-1/+3
| | | | | | | | | We had not been trying hard enough to resolve def names inside multiclasses that had complex concatenations, etc. Now we'll try harder. Patch by Amaury Sechet! llvm-svn: 237877
* Replace std::map<K, V*> with std::map<K, std::unique_ptr<V>> to handle ↵Craig Topper2014-12-111-1/+1
| | | | | | | | ownership and deletion of the values. Ideally we would store the MultiClasses by value directly in the maps, but I had some trouble with that before and this at least fixes the leak. llvm-svn: 223997
* Revert r222957 "Replace std::map<K, V*> with std::map<K, V> to handle ↵Craig Topper2014-11-301-1/+1
| | | | | | | | | | ownership and deletion of the values." Upon further review I think the MultiClass is being copied into the map instead of being moved due to the copy constructor on the nested Record type. This ultimately got exposed when the vector in DefPrototype vector was changed to hold unique_ptrs in another commit. This caused gcc 4.7 to fail due to the use of the copy constructor on unique_ptr with the error pointing back to one of the insert calls from this commit. Not sure why clang was able to build. This reverts commit 710cdf729f84b428bf41aa8d32dbdb35fff79fde. llvm-svn: 222971
* Replace std::map<K, V*> with std::map<K, V> to handle ownership and deletion ↵Craig Topper2014-11-291-1/+1
| | | | | | of the values. llvm-svn: 222957
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* Fix error in tablegen when either operand of !if is an empty list.Matt Arsenault2014-06-101-1/+1
| | | | | | !if([Something], []) would error with "No type for list". llvm-svn: 210572
* [C++] Use 'nullptr'.Craig Topper2014-04-281-6/+6
| | | | llvm-svn: 207394
* remove a bunch of unused private methodsNuno Lopes2014-03-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | found with a smarter version of -Wunused-member-function that I'm playwing with. Appologies in advance if I removed someone's WIP code. include/llvm/CodeGen/MachineSSAUpdater.h | 1 include/llvm/IR/DebugInfo.h | 3 lib/CodeGen/MachineSSAUpdater.cpp | 10 -- lib/CodeGen/PostRASchedulerList.cpp | 1 lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 10 -- lib/IR/DebugInfo.cpp | 12 -- lib/MC/MCAsmStreamer.cpp | 2 lib/Support/YAMLParser.cpp | 39 --------- lib/TableGen/TGParser.cpp | 16 --- lib/TableGen/TGParser.h | 1 lib/Target/AArch64/AArch64TargetTransformInfo.cpp | 9 -- lib/Target/ARM/ARMCodeEmitter.cpp | 12 -- lib/Target/ARM/ARMFastISel.cpp | 84 -------------------- lib/Target/Mips/MipsCodeEmitter.cpp | 11 -- lib/Target/Mips/MipsConstantIslandPass.cpp | 12 -- lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp | 21 ----- lib/Target/NVPTX/NVPTXISelDAGToDAG.h | 2 lib/Target/PowerPC/PPCFastISel.cpp | 1 lib/Transforms/Instrumentation/AddressSanitizer.cpp | 2 lib/Transforms/Instrumentation/BoundsChecking.cpp | 2 lib/Transforms/Instrumentation/MemorySanitizer.cpp | 1 lib/Transforms/Scalar/LoopIdiomRecognize.cpp | 8 - lib/Transforms/Scalar/SCCP.cpp | 1 utils/TableGen/CodeEmitterGen.cpp | 2 24 files changed, 2 insertions(+), 261 deletions(-) llvm-svn: 204560
* [TableGen] Use the same anonymous name as the prefix on all multiclass defsHal Finkel2014-01-021-1/+1
| | | | | | | | | | | | | | | | TableGen had been generating a different name for an anonymous multiclass's NAME for every def in the multiclass. This had an unfortunate side effect: it was impossible to reference one def within the multiclass from another (in the parameter list, for example). By making sure we only generate an anonymous name once per multiclass (which, as it turns out, requires only changing the name parameter to reference type), we can now concatenate NAME within the multiclass with a def name in order to generate a reference to that def. This does not matter so much, in and of itself, but is necessary for a follow-up commit that will fix variable capturing in implicit anonymous multiclass defs (and that is important). llvm-svn: 198340
* TableGen: Generate valid identifiers for anonymous recordsAlp Toker2013-12-211-2/+6
| | | | | | | | | | Backends like OptParserEmitter assume that record names can be used as valid identifiers. The period '.' in generated anonymous names broke that assumption, causing a build-time error and in practice forcing all records to be named. llvm-svn: 197869
* tblgen: Diagnose duplicate includes.Sean Silva2013-02-071-1/+1
| | | | | | | | | | | | | | | A double inclusion will pretty much always be an error in TableGen, so there's no point going on just to die with "def already defined" or whatnot. I'm not too thrilled about the "public: ... private: ..." to expose the DependenciesMapTy, but I really didn't see a better way to keep that type centralized. It's a smell that indicates that some refactoring is needed to make this code more loosely coupled. This should avoid all bugs of the same nature as PR15189. llvm-svn: 174582
* TableGen: Keep track of superclass reference ranges.Jordan Rose2013-01-101-1/+1
| | | | | | | | | | def foo : bar; ~~~ This allows us to produce more precise diagnostics about a certain superclass, and even provide fixits. llvm-svn: 172085
* tblgen: Factor out common code.Sean Silva2013-01-091-0/+1
| | | | llvm-svn: 171951
* Inline this into its only caller.Sean Silva2013-01-091-1/+0
| | | | | | | | | | | It's clearer and additionally this gets rid of the usage of `DefmID`, which doesn't really correspond to anything in the language (it was just used in the name of this parsing function which parsed a `MultiClassID` and returned that multiclass's record). This area of the code still needs a lot of work. llvm-svn: 171938
* Sort includes for all of the .h files under the 'lib' tree. These wereChandler Carruth2012-12-041-2/+2
| | | | | | | | | | missed in the first pass because the script didn't yet handle include guards. Note that the script is now able to handle all of these headers without manual edits. =] llvm-svn: 169224
* tblgen: Whitespace and 80-col cleanup.Sean Silva2012-10-041-11/+12
| | | | llvm-svn: 165190
* Simplify TGParser::ProcessForEachDefs.Jakob Stoklund Olesen2012-05-241-11/+9
| | | | | | Use static type checking. llvm-svn: 157430
* Remove stray semi-colon.Daniel Dunbar2012-02-281-1/+1
| | | | llvm-svn: 151629
* Add Foreach LoopDavid Greene2012-02-221-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some data structures to represent for loops. These will be referenced during object processing to do any needed iteration and instantiation. Add foreach keyword support to the lexer. Add a mode to indicate that we're parsing a foreach loop. This allows the value parser to early-out when processing the foreach value list. Add a routine to parse foreach iteration declarations. This is separate from ParseDeclaration because the type of the named value (the iterator) doesn't match the type of the initializer value (the value list). It also needs to add two values to the foreach record: the iterator and the value list. Add parsing support for foreach. Add the code to process foreach loops and create defs based on iterator values. Allow foreach loops to be matched at the top level. When parsing an IDValue check if it is a foreach loop iterator for one of the active loops. If so, return a VarInit for it. Add Emacs keyword support for foreach. Add VIM keyword support for foreach. Add tests to check foreach operation. Add TableGen documentation for foreach. Support foreach with multiple objects. Support non-braced foreach body with one object. Do not require types for the foreach declaration. Assume the iterator type from the iteration list element type. llvm-svn: 151164
* Process Defm Prefix as InitDavid Greene2011-10-191-1/+1
| | | | | | | Parse and process a defm prefix as an Init expression. This allows paste operations to create defm prefixes. llvm-svn: 142523
* Parse Def ID as ValueDavid Greene2011-10-191-1/+1
| | | | | | | Allow def and defm IDs to be general values. We need this for paste functionality. llvm-svn: 142522
* Make ID Parsing More FlexibleDavid Greene2011-10-191-4/+18
| | | | | | | | | | | | | | | | | | | Add a mode control to value and ID parsers. The two modes are: - Parse a value. Expect the parsed ID to map to an existing object. - Parse a name. Expect the parsed ID to not map to any existing object. The first is used when parsing an identifier to be looked up, for example a record field or template argument. The second is used for parsing declarations. Paste functionality implies that declarations can contain arbitrary expressions so we need to be able to call into the general value parser to parse declarations with paste operators. So we need a way to parse a value-like thing without expecting that the result will map to some existing object. This parse mode provides that. llvm-svn: 142519
* Make Template Arg Names InitsDavid Greene2011-10-191-2/+2
| | | | | | | | Allow template arg names to be Inits. This is further work to implement paste as it allows template names to participate in paste operations. llvm-svn: 142500
* Let SetValue Take and Init NameDavid Greene2011-10-191-1/+6
| | | | | | | Convert SetValue to take the value name as an Init. This allows us to set values for variables whose names are not yet fully resolved. llvm-svn: 142499
OpenPOWER on IntegriCloud