summaryrefslogtreecommitdiffstats
path: root/llvm/lib/TableGen/Record.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Add bang-operators !getop and !setop.Simon Tatham2019-12-111-0/+31
| | | | | | | | | | | | | | | | | | | | | | 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
* [TableGen] Permit dag operators to be unset.Simon Tatham2019-12-101-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | This is not a new semantic feature. The syntax `(? 1, 2, 3)` was disallowed by the parser in a dag //expression//, but there were already ways to sneak a `?` into the operator field of a dag //value//, e.g. by initializing it from a class template parameter which is then set to `?` by the instantiating `def`. This patch makes `?` in the operator slot syntactically legal, so it's now easy to construct dags with an unset operator. Also, the semantics of `!con` are relaxed so that it will allow a combination of set and unset operator fields in the dag nodes it's concatenating, with the restriction that all the operators that are //not// unset still have to agree with each other. Reviewers: hfinkel, nhaehnle Reviewed By: hfinkel, nhaehnle Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71195
* Add Record::getValueAsOptionalDef().John McCall2019-10-251-0/+15
| | | | | | Using `?` as an optional marker is very useful in Clang's AST-node emitters because otherwise we need a separate class just to encode the presence or absence of a base node reference.
* BitsInit::resolveReferences - silence static analyzer null dereference ↵Simon Pilgrim2019-10-141-1/+1
| | | | | | | | warning. NFCI. The static analyzer is warning about a potential null dereference, assert to check that the loop has set the cached pointer. llvm-svn: 374789
* [tblgen] Add getOperatorAsDef() to RecordDaniel Sanders2019-10-081-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While working with DagInit's, it's often the case that you expect the operator to be a reference to a def. This patch adds a wrapper for this common case to reduce the amount of boilerplate callers need to duplicate repeatedly. getOperatorAsDef() returns the record if the DagInit has an operator that is a DefInit. Otherwise, it prints a fatal error. There's only a few pre-existing examples in LLVM at the moment and I've left a few instances of the code this simplifies as they had more specific error messages than the generic one this produces. I'm going to be using this a fair bit in my subsequent patches. Reviewers: bogner, volkan, nhaehnle Reviewed By: nhaehnle Subscribers: nhaehnle, hiraditya, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lenary, s.egerton, pzheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68424 llvm-svn: 374101
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-1/+1
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [TableGen] Introduce !listsplat 'binary' operatorRoman Lebedev2019-04-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] Allow 2^63-1 and 2^63-2 as int literals.Simon Tatham2019-03-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | These two values correspond to the 'Empty' and 'Tombstone' special keys defined by DenseMapInfo<int64_t>, which means that neither one can be used as a key in DenseMap<int64_t, anything>. Hence, if you try to use either of those values as an int literal, IntInit::get() fails an assertion when it tries to insert them into its static cache of int-literal objects. Fixed by replacing the DenseMap with a std::map, which doesn't intrude on the space of legal values of the key type. Reviewers: nhaehnle, hfinkel, javedabsar, efriedma Reviewed By: efriedma Subscribers: fhahn, efriedma, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59016 llvm-svn: 355900
* TableGen: Allow lists to be concatenated through '#'Javed Absar2019-03-051-0/+18
| | | | | | | | | | | | | | | | | | | Currently one can concatenate strings using hash(#), but not lists, although that would be a natural thing to do. This patch allows one to write something like: def : A<!listconcat([1,2], [3,4])>; simply as : def : A<[1,2] # [3,4]>; This was missing feature was highlighted by Nicolai at FOSDEM talk. Reviewed by: nhaehnle, hfinkel Differential Revision: https://reviews.llvm.org/D58895 llvm-svn: 355414
* [tblgen] Track CodeInit origins when possibleDaniel Sanders2019-03-021-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an SMLoc to CodeInit that records the source line it originated from. This allows tablegen to point precisely at portions of code when reporting errors within the CodeInit. For example, in the upcoming GlobalISel combiner, it can report undefined expansions and point at the instance of the expansion. This is achieved using something like: SMLoc::getFromPointer(SMLoc::getPointer() + (StringRef - CodeInit::getValue())) The location is lost when producing a CodeInit by string concatenation so a fallback SMLoc is required (e.g. the Record::getLoc()) but that's pretty rare for CodeInits. There's a reasonable case for extending tracking of a couple other Init objects, for example StringInit's are often parsed and it would be good to point inside the string when reporting errors about that. However, location tracking also harms de-duplication. This is fine for CodeInit where there's only a few hundred of them (~160 for X86) and it may be worth it for StringInit (~86k up to ~1.9M for roughly 15MB increase for X86). However the origin tracking would be a _terrible_ idea for IntInit, BitInit, and UnsetInit. I haven't measured either of those three but BitInit would most likely be on the order of increasing the current 2 BitInit values up to billions. Reviewers: volkan, aditya_nandakumar, bogner, paquette, aemerson Reviewed By: paquette Subscribers: javed.absar, kristof.beyls, dexonsmith, llvm-commits, kristina Tags: #llvm Differential Revision: https://reviews.llvm.org/D58141 llvm-svn: 355245
* [Tablegen] Add support for the !mul operator.Nicola Zaghen2019-03-011-0/+3
| | | | | | | | | 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-0/+131
| | | | | | | | | | | | | | | | | 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] fix assert in !cast when used out of definition in a multiclassValery Pykhtin2018-10-101-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D53068 llvm-svn: 344134
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-4/+3
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [tblgen] Fix undefined behaviour when assigning integers to large bits<n>'sDaniel Sanders2018-09-211-1/+1
| | | | | | | | | | | | | | | | | | This code: bits<96> X = 0; was triggering undefined behaviour since it iterates over bits 0..95 and tests them against the IntInit using 1LL << I. This patch resolves the undefined behaviour by continuing to treat the IntInit as a 64-bit value and simply causing all bit tests in excess of 64-bits to report false. As a result, bits<96> X = -1; will be equivalent to: bits<96> X; let X{0-63} = -1; let X{64-95} = 0; llvm-svn: 342744
* TableGen: Allow foreach in multiclass to depend on template argsNicolai Haehnle2018-06-211-25/+0
| | | | | | | | | | | | | | | | | | | | 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-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Don't quote variable name when printing !foreach.Simon Tatham2018-05-021-3/+5
| | | | | | | | | | | | | | | | | An input !foreach expression such as !foreach(a, lst, !add(a, 1)) would be re-emitted by llvm-tblgen -print-records with the first argument in quotes, giving !foreach("a", lst, !add(a, 1)), which isn't valid TableGen input syntax. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46352 llvm-svn: 331351
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* [TableGen] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: stoklund, kparzysz, dsanders Reviewed By: dsanders Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45144 llvm-svn: 329451
* TableGen: Remove redundant loop in ListInit::resolveReferencesNicolai Haehnle2018-03-211-7/+2
| | | | | | | | | | | | | | | | Summary: Recursive lookups are handled by the Resolver, so the loop was purely a waste of runtime. Change-Id: I2bd23a68b478aea0bbac1a86ca7635adffa28688 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44624 llvm-svn: 328118
* TableGen: Streamline how defs are instantiatedNicolai Haehnle2018-03-211-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Explicitly forbid self-references to field membersNicolai Haehnle2018-03-191-3/+9
| | | | | | | | | | | | | | | | Summary: Otherwise, patterns like in the test case produce cryptic error messages about fields being resolved incompletely. Change-Id: I713c0191f00fe140ad698675803ab1f8823dc5bd Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44476 llvm-svn: 327850
* TableGen: Check the dynamic type of !cast<Rec>(string)Nicolai Haehnle2018-03-191-10/+33
| | | | | | | | | | | | | | | | | | | | | Summary: The docs already claim that this happens, but so far it hasn't. As a consequence, existing TableGen files get this wrong a lot, but luckily the fixes are all reasonably straightforward. To make this work with all the existing forms of self-references (since the true type of a record is only built up over time), the lookup of self-references in !cast is delayed until the final resolving step. Change-Id: If5923a72a252ba2fbc81a889d59775df0ef31164 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D44475 llvm-svn: 327849
* TableGen: Explicitly test some cases of self-references and !cast errorsNicolai Haehnle2018-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: These are cases of self-references that exist today in practice. Let's add tests for them to avoid regressions. The self-references in PPCInstrInfo.td can be expressed in a simpler way. Allowing this type of self-reference while at the same time consistently doing late-resolve even for self-references is problematic because there are references to fields that aren't in any class. Since there's no need for this type of self-reference anyway, let's just remove it. Change-Id: I914e0b3e1ae7adae33855fac409b536879bc3f62 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: nemanjai, wdng, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D44474 llvm-svn: 327848
* TableGen: Only fold when some operand made resolve progressNicolai Haehnle2018-03-191-3/+3
| | | | | | | | | | | | | | | | Summary: Make sure that we always fold immediately, so there's no point in attempting to re-fold when nothing changes. Change-Id: I069e1989455b6f2ca8606152f6adc1a5e817f1c8 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44198 llvm-svn: 327847
* TableGen: Move GenStrConcat to a helper function in BinOpInitNicolai Haehnle2018-03-191-13/+14
| | | | | | | | | | | | | | | Summary: Make it accessible for more users. Change-Id: Ib05f09ba14e7942ced5d2f24b205efa285e40cd5 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44196 llvm-svn: 327845
* TableGen: Remove the cast-from-string-to-variable-reference featureNicolai Haehnle2018-03-191-48/+13
| | | | | | | | | | | | | | | | | | | Summary: Cast-from-string for records isn't going away, but cast-from-string for variables is a pretty dodgy feature to have, especially when referencing template arguments. It's doubtful that this ever worked in a reliable way, and nobody seems to be using it, so let's get rid of it and get some related cleanups. Change-Id: I395ac8a43fef4cf98e611f2f552300d21e99b66a Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44195 llvm-svn: 327844
* TableGen: Add !ne, !le, !lt, !ge, and !gt comparisonsNicolai Haehnle2018-03-141-10/+35
| | | | | | | | Change-Id: I8e2ece677268972d578a787467f7ef52a1f33a71 Differential revision: https://reviews.llvm.org/D44114 llvm-svn: 327496
* TableGen: Allow dag operators to be resolved lateNicolai Haehnle2018-03-141-2/+7
| | | | | | | | Change-Id: I51bb80fd5c48c8ac441ab11e43d43c1b91b4b590 Differential revision: https://reviews.llvm.org/D44113 llvm-svn: 327495
* TableGen: Add !dag function for constructionNicolai Haehnle2018-03-141-0/+25
| | | | | | | | | | | | | | | 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: Allow arbitrary list values as ranges of foreachNicolai Haehnle2018-03-091-7/+8
| | | | | | | | | 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: More helpful error messagesNicolai Haehnle2018-03-091-8/+22
| | | | | Change-Id: Ic78afd0cd765fdb4cf1b7ecfb6bba22653ce6d29 llvm-svn: 327118
* TableGen: add !isa operationNicolai Haehnle2018-03-091-0/+62
| | | | | | | | Change-Id: Iddb724c3ae706d82933a2d82c91d07e0e36b30e3 Differential revision: https://reviews.llvm.org/D44105 llvm-svn: 327117
* TableGen: Add !foldl operationNicolai Haehnle2018-03-061-0/+71
| | | | | Change-Id: I63d67bf6e0b315e2d3360e47e3b62c9517f38987 llvm-svn: 326790
* TableGen: Delay instantiating inline anonymous recordsNicolai Haehnle2018-03-061-0/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Only instantiate anonymous records once all variable references in template arguments have been resolved. This allows patterns like the new test case, which in practice can appear in expressions like: class IntrinsicTypeProfile<list<LLVMType> ty, int shift> { list<LLVMType> types = !listconcat(ty, [llvm_any_ty, LLVMMatchType<shift>]); } class FooIntrinsic<IntrinsicTypeProfile P, ...> : Intrinsic<..., P.types, ...>; Without this change, the anonymous LLVMMatchType instantiation would never get resolved. Another consequence of this change is that anonymous inline instantiations are uniqued via the folding set of the newly introduced VarDefInit. Change-Id: I7a7041a20e297cf98c9109b28d85e64e176c932a Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43756 llvm-svn: 326788
* TableGen: Move getNewAnonymousName into RecordKeeperNicolai Haehnle2018-03-061-0/+6
| | | | | | | | | | | | | | | | 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: Explicitly check whether a record has been resolvedNicolai Haehnle2018-03-061-0/+26
| | | | | | | | | | | | | | | | | | Summary: There are various places where resolving and constant folds can get stuck, especially around casts. We don't always signal an error for those, because in many cases they can legitimately occur without being an error in the "untaken branch" of an !if. Change-Id: I3befc0e4234c8e6cc61190504702918c9f29ce5c Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43754 llvm-svn: 326786
* TableGen: Allow !cast of records, cleanup conversion machineryNicolai Haehnle2018-03-061-122/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Distinguish two relationships between types: is-a and convertible-to. For example, a bit is not an int or vice versa, but they can be converted into each other (with range checks that you can think of as "dynamic": unlike other type checks, those range checks do not happen during parsing, but only once the final values have been established). Actually converting initializers between types is subtle: even when values of type A can be converted to type B (e.g. int into string), it may not be possible to do so with a concrete initializer (e.g., a VarInit that refers to a variable of type int cannot be immediately converted to a string). For this reason, distinguish between getCastTo and convertInitializerTo: the latter implements the actual conversion when appropriate, while the former will first try to do the actual conversion and fall back to introducing a !cast operation so that the conversion will be delayed until variable references have been resolved. To make the approach of adding !cast operations to work, !cast needs to fallback to convertInitializerTo when the special string <-> record logic does not apply. This enables casting records to a subclass, although that new functionality is only truly useful together with !isa, which will be added in a later change. The test is removed because it uses !srl on a bit sequence, which cannot really be supported consistently, but luckily isn't used anywhere either. Change-Id: I98168bf52649176654ed2ec61a29bdb29970cfe7 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43753 llvm-svn: 326785
* TableGen: Simplify BitsInit::resolveReferencesNicolai Haehnle2018-03-061-35/+16
| | | | | | | | | | | | | | | | | | | | Summary: No functional change intended. The removed code has a loop for recursive resolving, which is superseded by the recursive resolving done by the Resolver implementations. Add a test case which was broken by an earlier version of this change. Change-Id: Ib208d037b77a8bbb725977f1388601fc984723d8 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43655 llvm-svn: 326784
* TableGen: Generalize record types to fix typeIsConvertibleTo et al.Nicolai Haehnle2018-03-061-36/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow RecordRecTy to represent the type "subclass of N superclasses", where N may be zero. Furthermore, generate RecordRecTy instances only with actual classes in the list. Keeping track of multiple superclasses is required to resolve the type of a list correctly in some cases. The old code relied on the incorrect behavior of typeIsConvertibleTo, and an earlier version of this change relied on a modified ordering of superclasses (it was committed in r325884 and then reverted because unfortunately some of clang-tblgen's backends depend on the ordering). Previously, the DefInit for each Record would have a RecordRecTy of that Record as its type. Now, all defs with the same superclasses will share the same type. This allows us to be more consistent about type checks involving records: - typeIsConvertibleTo actually requires the LHS to be a subtype of the RHS - resolveTypes will return the least supertype of given record types in all cases - different record types in the two branches of an !if are handled correctly Add a test that used to be accepted without flagging the obvious type error. Change-Id: Ib366db1a4e6a079f1a0851e469b402cddae76714 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43680 llvm-svn: 326783
* TableGen: Resolve all template args simultaneously in AddSubClassNicolai Haehnle2018-03-051-19/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: Use the new resolver interface more explicitly, and avoid traversing all the initializers multiple times. Add a test case for a pattern that was broken by an earlier version of this change. An additional change is that we now remove *all* template arguments after resolving them. Change-Id: I86c828c8cc84c18b052dfe0f64c0d5cbf3c4e13c Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43652 llvm-svn: 326706
* TableGen: Reimplement !foreach using the resolving mechanismNicolai Haehnle2018-03-051-70/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This changes the syntax of !foreach so that the first "parameter" is a new syntactic variable: !foreach(x, lst, expr) will define the variable x within the scope of expr, and evaluation of the !foreach will substitute elements of the given list (or dag) for x in expr. Aside from leading to a nicer syntax, this allows more complex expressions where x is deeply nested, or even constant expressions in which x does not occur at all. !foreach is currently not actually used anywhere in trunk, but I plan to use it in the AMDGPU backend. If out-of-tree targets are using it, they can adjust to the new syntax very easily. Change-Id: Ib966694d8ab6542279d6bc358b6f4d767945a805 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits, tpr Differential Revision: https://reviews.llvm.org/D43651 llvm-svn: 326705
* TableGen: Introduce an abstract variable resolver interfaceNicolai Haehnle2018-03-051-48/+78
| | | | | | | | | | | | | | | | | Summary: The intention is to allow us to more easily restructure how resolving is done, e.g. resolving multiple variables simultaneously, or using the resolving mechanism to implement !foreach. Change-Id: I4b976b54a32e240ad4f562f7eb86a4d663a20ea8 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43564 llvm-svn: 326704
* TableGen: Remove VarInit::getFieldTypeNicolai Haehnle2018-02-251-7/+0
| | | | | | | | | | | | | | It is redundant with the implementation in TypedInit. Change-Id: I8ab1fb5c77e4923f7eb3ffae5889f0f8af6093b4 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43678 llvm-svn: 326061
* TableGen: Get rid of Init::getFieldInitNicolai Haehnle2018-02-251-24/+6
| | | | | | | | | | | | | | | | | | | | Summary: FieldInit will just rely on the standardized resolving mechanism to give us DefInits for folding, thus simplifying the code. Unlike the removal of resolveListElementReference, this shouldn't have performance implications, because DefInits do not recurse inside their record. Change-Id: Id4544c774c9d9ee92f293615af6ecff706453f21 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43563 llvm-svn: 326060
* TableGen: Remove Init::resolveListElementReferenceNicolai Haehnle2018-02-251-88/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: Resolving a VarListElementInit should just resolve the list and then take its element. This eliminates a lot of duplicated logic and simplifies the next steps of refactoring resolveReferences. This does potentially cause sub-elements of the entire list to be resolved resulting in more work, but I didn't notice a measurable change in performance, and a later patch adds a caching mechanism that covers at least the common case of `var[i]` in a more generic way. Change-Id: I7b59185b855c7368585c329c31e5be38c5749dac Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43562 llvm-svn: 326059
* Revert "TableGen: Fix typeIsConvertibleTo for record types"Nicolai Haehnle2018-02-231-10/+4
| | | | | | | | | | This reverts r325884. Clang's TableGen has dependencies on the exact ordering of superclasses. Revert this change fully for now to fix the build. Change-Id: Ib297f5571cc7809f00838702ad7ab53d47335b26 llvm-svn: 325891
* TableGen: Fix typeIsConvertibleTo for record typesNicolai Haehnle2018-02-231-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Only check whether the left-hand side type is a subclass (or equal to) the right-hand side type. This requires a further fix in handling !if expressions and in type resolution. Furthermore, reverse the order of superclasses so that resolveTypes will find a least common ancestor at least in simple cases. Add a test that used to be accepted without flagging the obvious type error. Change-Id: Ib366db1a4e6a079f1a0851e469b402cddae76714 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43559 llvm-svn: 325884
OpenPOWER on IntegriCloud