summaryrefslogtreecommitdiffstats
path: root/llvm/test/TableGen
Commit message (Collapse)AuthorAgeFilesLines
* Merging r339073:Hans Wennborg2018-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r339073 | stella.stamenova | 2018-08-07 00:37:44 +0200 (Tue, 07 Aug 2018) | 14 lines [lit, python] Always add quotes around the python path in lit Summary: The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes. This change updates several configuration files which specify the path to python as a substitution and also remove quotes from existing tests. Reviewers: asmith, zturner, alexshap, jakehehrlich Reviewed By: zturner, alexshap, jakehehrlich Subscribers: mehdi_amini, nemanjai, eraman, kbarton, jakehehrlich, steven_wu, dexonsmith, stella.stamenova, delcypher, llvm-commits Differential Revision: https://reviews.llvm.org/D50206 ------------------------------------------------------------------------ llvm-svn: 339541
* [json, test] Fix the json.td test - the path to python could contain spacesStella Stamenova2018-07-131-1/+1
| | | | | | | | | | | | | | Summary: The path to the python executable can contain spaces, so it should be specified with quotes. Reviewers: asmith, simon_tatham Reviewed By: simon_tatham Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49258 llvm-svn: 337006
* [TableGen] Add a general-purpose JSON backend.Simon Tatham2018-07-112-0/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The aim of this backend is to output everything TableGen knows about the record set, similarly to the default -print-records backend. But where -print-records produces output in TableGen's input syntax (convenient for humans to read), this backend produces it as structured JSON data, which is convenient for loading into standard scripting languages such as Python, in order to extract information from the data set in an automated way. The output data contains a JSON representation of the variable definitions in output 'def' records, and a few pieces of metadata such as which of those definitions are tagged with the 'field' prefix and which defs are derived from which classes. It doesn't dump out absolutely every piece of knowledge it _could_ produce, such as type information and complicated arithmetic operator nodes in abstract superclasses; the main aim is to allow consumers of this JSON dump to essentially act as new backends, and backends don't generally need to depend on that kind of data. The new backend is implemented as an EmitJSON() function similar to all of llvm-tblgen's other EmitFoo functions, except that it lives in lib/TableGen instead of utils/TableGen on the basis that I'm expecting to add it to clang-tblgen too in a future patch. To test it, I've written a Python script that loads the JSON output and tests properties of it based on comments in the .td source - more or less like FileCheck, except that the CHECK: lines have Python expressions after them instead of textual pattern matches. Reviewers: nhaehnle Reviewed By: nhaehnle Subscribers: arichardson, labath, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46054 llvm-svn: 336771
* [TableGen] Increase the number of supported decoder fix-ups.Sander de Smalen2018-07-053-18/+18
| | | | | | | | | | | | | | | | The vast number of added instructions for SVE causes TableGen to fail with an assertion: Assertion `Delta < 65536U && "disassembler decoding table too large!"' This patch increases the number of supported decoder fix-ups. Reviewers: dmgreen, stoklund, petpav01 Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D48937 llvm-svn: 336334
* [IR] Split Intrinsics.inc into enums and implementationsReid Kleckner2018-06-233-3/+3
| | | | | | | | | | | | | | | | | | | Implements PR34259 Intrinsics.h is a very popular header. Most LLVM TUs care about things like dbg_value, but they don't care how they are implemented. After I split these out, IntrinsicImpl.inc is 1.7 MB, so this saves each LLVM TU from scanning 1.7 MB of source that gets pre-processed away. It also means we can modify intrinsic properties without triggering a full rebuild, but that's probably less of a win. I think the next best thing to do would be to split out the target intrinsics into their own header. Very, very few TUs care about target-specific intrinsics. It's very hard to split up the target independent intrinsics like llvm.expect, assume, and dbg.value, though. llvm-svn: 335407
* TableGen/SearchableTables: Support more generic enums and tablesNicolai Haehnle2018-06-213-9/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is essentially a rewrite of the backend which introduces TableGen base classes GenericEnum, GenericTable, and SearchIndex. They allow generating custom enums and tables with lookup functions using separately defined records as the underlying database. Also added as part of this change: - Lookup functions may use indices composed of multiple fields. - Instruction fields are supported similar to Intrinsic fields. - When the lookup key has contiguous numeric values, the lookup function will directly index into the table instead of using a binary search. The existing SearchableTable functionality is internally mapped to the new primitives. Change-Id: I444f3490fa1dbfb262d7286a1660a2c4308e9932 Reviewers: arsenm, tra, t.p.northover Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D48013 llvm-svn: 335225
* TableGen: Allow foreach in multiclass to depend on template argsNicolai Haehnle2018-06-212-2/+105
| | | | | | | | | | | | | | | | | | | | 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
* [globalisel][tablegen] Add support for C++ predicates on PatFrags and use it ↵Daniel Sanders2018-06-151-6/+15
| | | | | | | | | | | | | | | | | | | | | to support BFC on ARM. So far, we've only handled special cases of PatFrag like ImmLeaf. This patch adds support for the remaining cases using similar mechanisms. Like most C++ code from SelectionDAG, GISel and DAGISel expect to operate on different types and representations and as such the code is not compatible between the two. It's therefore necessary to add an alternative implementation in the GISelPredicateCode field. The target test for this feature could easily be done with IntImmLeaf and this would save on a little boilerplate. The reason I've chosen to implement this using PatFrag.GISelPredicateCode and not IntImmLeaf is because I was unable to find a rule that was blocked solely by lack of support for PatFrag predicates. I found that the ones I investigated as being likely candidates for the test were further blocked by other things. llvm-svn: 334871
* TableGen: Streamline the semantics of NAMENicolai Haehnle2018-06-045-49/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [GlobalISel][InstructionSelect] Moving Reg Bank Checks forward, perf patch 9Roman Tereshin2018-05-231-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917). In this commit we move register bank checks back from epilogue of every rule matcher to a position locally close to the rest of the checks for a particular (nested) instruction. This increases the number of common conditions within 2nd level groups. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by about 2% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64 (cross-compile on x86). Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333144
* [GlobalISel][InstructionSelect] Maximizing # of Group's common conditions, ↵Roman Tereshin2018-05-231-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | perf patch 8 This patch continues a series of patches started by r332907 (reapplied as r332917). In this commit we greedily stuff 2nd level GroupMatcher's common conditions with as many predicates as possible. This is purely post-processing and it doesn't change which rules are put into the groups in the first place: that decision is made by looking at the first common predicate only. The compile time improvements are minor and well within error margin, however, it's highly improbable that this transformation could pessimize performance, thus I'm still committing it for potential gains for targets not implementing GlobalISel yet and out of tree targets. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333139
* [GlobalISel][InstructionSelect] Moving type checks forward, perf patch 6Roman Tereshin2018-05-231-17/+27
| | | | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917) In this commit we sort type checks towards the beginning of every rule within the MatchTable as they fail often and it's best to fail early. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by roughly 7% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64. The amalgamation is a large single-file C-source that makes compiler backend performance improvements to stand out from frontend. It's also a part of CTMark. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333114
* [GlobalISel][InstructionSelect] MatchTable second level grouping, perf patch 5Roman Tereshin2018-05-231-3/+87
| | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917) In this commit we start grouping rules with common first condition on the second level of the table. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by roughly 13% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333053
* [GlobalISel][InstructionSelect] Switching MatchTable over opcodes, perf patch 4Roman Tereshin2018-05-221-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch continues a series of patches started by r332907 (reapplied as r332917) In this commit we introduce a new matching opcode GIM_SwitchOpcode that implements a jump table over opcodes and start emitting them for root instructions. This is expected to decrease time GlobalISel spends in its InstructionSelect pass by roughly 20% for an -O0 build as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64. To some degree, we assume here that the opcodes form a dense set, which is true at the moment for all upstream targets given the limitations of our rule importing mechanism. It might not be true for out of tree targets, specifically due to pseudo's. If so, we might noticeably increase the size of the MatchTable with this patch due to padding zeros. This will be addressed later. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 333017
* [FastISel] Permit instructions to be skipped for FastISel generation.Simon Dardis2018-05-221-0/+37
| | | | | | | | | | | | | | | | | | | Some ISA's such as microMIPS32(R6) have instructions which are near identical for code generation purposes, e.g. xor and xor16. These instructions take the same value types for operands and return values, have the same instruction predicates and map to the same ISD opcode. (These instructions do differ by register classes.) In such cases, the FastISel generator rejects the instruction definition. This patch borrows the 'FastIselShouldIgnore' bit from rL129692 and enables applying it to an instruction definition. Reviewers: mcrosier Differential Revision: https://reviews.llvm.org/D46953 llvm-svn: 332983
* [GlobalISel][InstructionSelect] Removing redundant num operands and nested ↵Roman Tereshin2018-05-221-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | def operands checks, perf patch 2 This patch continues a series of patches that decrease time spent by GlobalISel in its InstructionSelect pass by roughly 60% for -O0 builds for large inputs as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64. This commit specifically removes number of operands checks that are redundant if the instruction's opcode already guarantees that number of operands (or more), and also avoids any kind of checks on a def operand of a nested instruction as everything about it was already checked at its use. The expected performance implication is about 3% off InstructionSelect comparing to the baseline (before the series of patches) This patch also contains a bit of NFC changes required for further patches in the series. Every commit planned shares the same Phabricator Review. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 332945
* Reapply r332907 "[GlobalISel] Improving InstructionSelect's performance by ↵Roman Tereshin2018-05-211-730/+658
| | | | | | | | | | | | reducing MatchTable..." Apparently the compile time problem was caused by the fact that not all compilers / STL implementations can automatically convert std::unique_ptr<Derived> to std::unique_ptr<Base>. Fixed (hopefully) by making sure it's std::unique_ptr<Derived>&& (rvalue ref) to std::unique_ptr<Base> conversion instead. llvm-svn: 332917
* Revert r332907 "[GlobalISel] Improving InstructionSelect's performance by ↵Roman Tereshin2018-05-211-658/+730
| | | | | | | | reducing MatchTable..." There is a compile time error I didn't see locally, investigating now. llvm-svn: 332912
* [GlobalISel] Improving InstructionSelect's performance by reducing ↵Roman Tereshin2018-05-211-730/+658
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MatchTable, mostly NFC, perf patch 1 This patch starts a series of patches that decrease time spent by GlobalISel in its InstructionSelect pass by roughly 60% for -O0 builds for large inputs as measured on sqlite3-amalgamation (http://sqlite.org/download.html) targeting AArch64. The performance improvements are achieved solely by reducing the number of matching GIM_* opcodes executed by the MatchTable's interpreter during the selection by approx. a factor of 30, which also brings contribution of this particular part of the selection process to the overall runtime of InstructionSelect pass down from approx. 60-70% to 5-7%, thus making further improvements in this particular direction not very profitable. The improvements described above are expected for any target that doesn't have many complex patterns. The targets that do should strictly benefit from the changes, but by how much exactly is hard to estimate beforehand. It's also likely that such target WILL benefit from further improvements to MatchTable, most likely the ones that bring it closer to a perfect decision tree. This commit specifically is rather large mostly NFC commit that does necessary preparation work and refactoring, there will be a following series of small patches introducing a specific optimization each shortly after. This commit specifically is expected to cause a small compile time regression (around 2.5% of InstructionSelect pass time), which should be fixed by the next commit of the series. Every commit planned shares the same Phabricator Review. Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar Reviewed By: qcolombet Subscribers: rovka, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D44700 llvm-svn: 332907
* [globalisel] Update GlobalISel emitter to match new representation of ↵Daniel Sanders2018-05-051-43/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | extending loads Summary: Previously, a extending load was represented at (G_*EXT (G_LOAD x)). This had a few drawbacks: * G_LOAD had to be legal for all sizes you could extend from, even if registers didn't naturally hold those sizes. * All sizes you could extend from had to be allocatable just in case the extend went missing (e.g. by optimization). * At minimum, G_*EXT and G_TRUNC had to be legal for these sizes. As we improve optimization of extends and truncates, this legality requirement would spread without considerable care w.r.t when certain combines were permitted. * The SelectionDAG importer required some ugly and fragile pattern rewriting to translate patterns into this style. This patch changes the representation to: * (G_[SZ]EXTLOAD x) * (G_LOAD x) any-extends when MMO.getSize() * 8 < ResultTy.getSizeInBits() which resolves these issues by allowing targets to work entirely in their native register sizes, and by having a more direct translation from SelectionDAG patterns. Each extending load can be lowered by the legalizer into separate extends and loads, however a target that supports s1 will need the any-extending load to extend to at least s8 since LLVM does not represent memory accesses smaller than 8 bit. The legalizer can widenScalar G_LOAD into an any-extending load but sign/zero-extending loads need help from something else like a combiner pass. A follow-up patch that adds combiner helpers for for this will follow. The new representation requires that the MMO correctly reflect the memory access so this has been corrected in a couple tests. I've also moved the extending loads to their own tests since they are (mostly) separate opcodes now. Additionally, the re-write appears to have invalidated two tests from select-with-no-legality-check.mir since the matcher table no longer contains loads that result in s1's and they aren't legal in AArch64 anymore. Depends on D45540 Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, javed.absar Reviewed By: rtereshin Subscribers: javed.absar, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D45541 llvm-svn: 331601
* [GlobalISel][InstructionSelect] Refactoring out a getMatchTable virtual ↵Roman Tereshin2018-05-021-4/+9
| | | | | | | | | | | | | | | | | | | | | method + other small NFC's The main goal is to share getMatchTable between the Instruction Selector and the Testgen. The commit also contains some NFC only loosely related to refactoring out the getMatchTable, but strongly related to the initial Testgen patch (see https://reviews.llvm.org/D43962) Reviewers: dsanders, aemerson Reviewed By: dsanders Subscribers: rovka, kristof.beyls, llvm-commits, dsanders Differential Revision: https://reviews.llvm.org/D46096 llvm-svn: 331395
* [TableGen] Don't quote variable name when printing !foreach.Simon Tatham2018-05-021-0/+3
| | | | | | | | | | | | | | | | | 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
* TableGen: Support Intrinsic values in SearchableTableNicolai Haehnle2018-04-011-0/+85
| | | | | | | | | | | | | | | | | | | | | Summary: We will use this in the AMDGPU backend in a subsequent patch in the stack to lookup target-specific per-intrinsic information. The generic CodeGenIntrinsic machinery is used to ensure that, even though we don't calculate actual enum values here, we do get the intrinsics in the right order for the binary search index. Change-Id: If61cd5587963a4c5a1cc53df1e59c5e4dec1f9dc Reviewers: arsenm, rampitec, b-sumner Subscribers: wdng, tpr, llvm-commits Differential Revision: https://reviews.llvm.org/D44935 llvm-svn: 328937
* TableGen: Streamline how defs are instantiatedNicolai Haehnle2018-03-214-2/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+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-192-1/+32
| | | | | | | | | | | | | | | | | | | | | 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-193-0/+71
| | | | | | | | | | | | | | | | | | | | | | | 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: Remove the cast-from-string-to-variable-reference featureNicolai Haehnle2018-03-191-1/+1
| | | | | | | | | | | | | | | | | | | 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-143-4/+83
| | | | | | | | 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/+15
| | | | | | | | Change-Id: I51bb80fd5c48c8ac441ab11e43d43c1b91b4b590 Differential revision: https://reviews.llvm.org/D44113 llvm-svn: 327495
* TableGen: Type-check BinOpsNicolai Haehnle2018-03-145-0/+76
| | | | | | | | | | | Additionally, allow more than two operands to !con, !add, !and, !or in the same way as is already allowed for !listconcat and !strconcat. Change-Id: I9659411f554201b90cd8ed7c7e004d381a66fa93 Differential revision: https://reviews.llvm.org/D44112 llvm-svn: 327494
* TableGen: Allow ? in listsNicolai Haehnle2018-03-141-2/+2
| | | | | | | | | | This makes using !dag more convenient in some cases. Change-Id: I0a8c35e15ccd1ecec778fd1c8d64eee38d74517c Differential revision: https://reviews.llvm.org/D44111 llvm-svn: 327493
* TableGen: Add !dag function for constructionNicolai Haehnle2018-03-141-0/+95
| | | | | | | | | | | | | | | 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-092-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | 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-0/+19
| | | | | | | | | 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/+39
| | | | | | | | 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-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Explicitly check whether a record has been resolvedNicolai Haehnle2018-03-062-12/+2
| | | | | | | | | | | | | | | | | | 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-064-8/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+30
| | | | | | | | | | | | | | | | | | | | 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-062-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+16
| | | | | | | | | | | | | | | | | | | | | | 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-055-59/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Allow NAME in template arguments in defm in multiclassNicolai Haehnle2018-03-052-0/+82
| | | | | | | | | | | | | | | | | | | | Summary: NAME has already worked for def in a multiclass, since the (protoype) record including its NAME variable is created before parsing the superclasses. Since defm's do not have an associated single record, support for NAME has to be implemented differently here. Original test cases provided by Artem Belevich (tra) Change-Id: I933b74f328c0ff202e7dc23a35b78f3505760cc9 Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43656 llvm-svn: 326700
* Revert "TableGen: Fix typeIsConvertibleTo for record types"Nicolai Haehnle2018-02-232-36/+1
| | | | | | | | | | 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-232-1/+36
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* TableGen: Add !size operationNicolai Haehnle2018-02-231-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | 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: Allow implicit casting between string and codeNicolai Haehnle2018-02-221-0/+23
| | | | | | | | | | | | | | | | | | | | | Summary: Perhaps the distinction between the two should be removed entirely in the long term, and the [{ ... }] syntax should just be a convenient way of writing multi-line strings. In the meantime, a lot of existing .td files are quite relaxed about string vs. code, and this change allows switching on more consistent type checks without breaking those. Change-Id: If85e3e04469e41b58e2703b62ac0032d2711713c Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43557 llvm-svn: 325799
* TableGen: Fix type deduction for !foreachNicolai Haehnle2018-02-221-0/+12
| | | | | | | | | | | | | | | | | Summary: In the case of !foreach(id, input-list, transform) where the type of input-list is list<A> and the type of transform is B, we now correctly deduce list<B> as the type of the !foreach. Change-Id: Ia19dd65eecc5991dd648280ba6a15f6a20fd61de Reviewers: arsenm, craig.topper, tra, MartinO Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D43555 llvm-svn: 325797
OpenPOWER on IntegriCloud