summaryrefslogtreecommitdiffstats
path: root/llvm/test/TableGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [GlobalISel] Check LLT size matches memory size for non-truncating stores.Amara Emerson2019-08-021-1/+16
| | | | | | | | This was causing a bug where non-truncating stores would be selected instead of truncating ones. Differential Revision: https://reviews.llvm.org/D64845 llvm-svn: 367737
* TableGen: Add MinAlignment predicateMatt Arsenault2019-07-311-16/+21
| | | | | | | | | | AMDGPU uses some custom code predicates for testing alignments. I'm still having trouble comprehending the behavior of predicate bits in the PatFrag hierarchy. Any attempt to abstract these properties unexpectdly fails to apply them. llvm-svn: 367373
* [TableGen] Do not set ReadNone attribute on intrinsics with side effectsMomchil Velikov2019-07-171-0/+39
| | | | | | | | | | | If an intrinsic is defined without outputs, but having side effects, it still can be removed completely from the program. This patch makes TableGen not set Attribute::ReadNone for intrinsics which are declared with IntrHasSideEffects. Differential Revision: https://reviews.llvm.org/D64414 llvm-svn: 366312
* [TableGen] Generate offsets into a flat array for getOperandTypeJustin Bogner2019-07-161-2/+2
| | | | | | | | | | Rather than an array of std::initializer_list, generate a table of offsets and a flat array of the operands for getOperandType. This is a bit more efficient on platforms that don't manage to get the array of inintializer_lists initialized at link time (I'm looking at you macOS). It's also quite quite a bit faster to compile. llvm-svn: 366278
* [TableGen] Add "getOperandType" to get operand types from opcode/opidxJustin Bogner2019-07-161-0/+40
| | | | | | | | | | | | | The InstrInfoEmitter outputs an enum called "OperandType" which gives numerical IDs to each operand type. This patch makes use of this enum to define a function called "getOperandType", which allows looking up the type of an operand given its opcode and operand index. Patch by Nicolas Guillemot. Thanks! Differential Revision: https://reviews.llvm.org/D63320 llvm-svn: 366274
* TableGen/GlobalISel: Fix handling of truncstore patternsMatt Arsenault2019-07-151-0/+38
| | | | | | | | | | | | This was failing to import the AMDGPU truncstore patterns. The truncating stores from 32-bit to 8/16 were then somehow being incorrectly selected to a 4-byte store. A separate check is emitted for the LLT size in comparison to the specific memory VT, which looks strange to me but makes sense based on the hierarchy of PatFrags used for the default truncstore PatFrags. llvm-svn: 366129
* TableGen: Add address space to matchersMatt Arsenault2019-07-151-0/+85
| | | | | | | | | | | | | | | | | Currently AMDGPU uses a CodePatPred to check address spaces from the MachineMemOperand. Introduce a new first class property so that the existing patterns can be easily modified to uses the new generated predicate, which will also be handled for GlobalISel. I would prefer these to match against the pointer type of the instruction, but that would be difficult to get working with SelectionDAG compatbility. This is much easier for now and will avoid a painful tablegen rewrite for all the loads and stores. I'm also not sure if there's a better way to encode multiple address spaces in the table, rather than putting the number to expect. llvm-svn: 366128
* [CodeGen] Add larger vector types for i32 and f32David Majnemer2019-07-071-1/+1
| | | | | | | | | | Some out of tree backend require larger vector type. Since maintaining the changes out of tree is difficult due to the many manual changes needed when adding a new type we are adding it even if no backend currently use it. Differential Revision: https://reviews.llvm.org/D64141 Patch by Thomas Raoux! llvm-svn: 365274
* [TableGen] Allow DAG isel patterns to override default operands.Simon Tatham2019-07-041-0/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a Tablegen instruction description uses `OperandWithDefaultOps`, isel patterns for that instruction don't have to fill in the default value for the operand in question. But the flip side is that they actually //can't// override the defaults even if they want to. This will be very inconvenient for the Arm backend, when we start wanting to write isel patterns that generate the many MVE predicated vector instructions, in the form with predication actually enabled. So this small Tablegen fix makes it possible to write an isel pattern either with or without values for a defaulted operand, and have the default values filled in only if they are not overridden. If all the defaulted operands come at the end of the instruction's operand list, there's a natural way to match them up to the arguments supplied in the pattern: consume pattern arguments until you run out, then fill in any missing instruction operands with their default values. But if defaulted and non-defaulted operands are interleaved, it's less clear what to do. This does happen in existing targets (the first example I came across was KILLGT, in the AMDGPU/R600 backend), and of course they expect the previous behaviour (that the default for those operands is used and a pattern argument is not consumed), so for backwards compatibility I've stuck with that. Reviewers: nhaehnle, hfinkel, dmgreen Subscribers: mehdi_amini, javed.absar, tpr, kristof.beyls, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63814 llvm-svn: 365114
* Teach TableGen Intrin Emitter to handle LLVMPointerType<llvm_any_ty>Erich Keane2019-06-261-0/+53
| | | | | | | | | | r363233 rewrote a bunch of the Intrin Emitter code, however the new function to update the arg codes did not properly consider a pointer to an any. This patch adds that logic. Differential Revision: https://reviews.llvm.org/D63507 llvm-svn: 364364
* TableGen: Handle nontrivial foreach range boundsMatt Arsenault2019-05-227-0/+193
| | | | | | | | | | | | 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
* TableGen: support #ifndef in addition to #ifdef.Tim Northover2019-05-144-1/+19
| | | | | | | TableGen has a limited preprocessor, which only really supports easier. llvm-svn: 360670
* [TableGen] Include schedule model name in diagnostic.Simon Tatham2019-04-151-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | If you have more than one schedule model in your TableGen target definitions, then the diagnostic "No schedule information for instruction 'foo'" is rather unhelpful, because it doesn't tell you _which_ schedule model is missing the necessary information (or, as it might be, missing the UnsupportedFeatures definition that would stop it thinking it needed it). Extended the message to include the name of the schedule model that it's complaining about. Reviewers: nhaehnle, hfinkel, javedabsar, efriedma, javed.absar Reviewed By: javed.absar Subscribers: javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60559 llvm-svn: 358389
* [TableGen] Introduce !listsplat 'binary' operatorRoman Lebedev2019-04-101-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] Let list elements have a trailing commaJaved Absar2019-03-261-0/+4
| | | | | | | | | | | Let lists have an trailing comma to allow cleaner diffs e.g: def : Features<[FeatureA, FeatureB, ]>; Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D59247 llvm-svn: 356986
* [TableGen] Give meaningful msg for def use in multiclassJaved Absar2019-03-261-0/+10
| | | | | | | | | | | | | When one mistakenly specifies 'def' instead of using 'defm', the error message is quite misleading: 'Couldn't find class..' Instead, it should recommend using defm if the multiclass of same name exists. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D59294 llvm-svn: 356985
* [CodeGen] Defined MVTs v3i32, v3f32, v5i32, v5f32Tim Renouf2019-03-171-1/+1
| | | | | | | | | AMDGPU would like to use these MVTs. Differential Revision: https://reviews.llvm.org/D58901 Change-Id: I6125fea810d7cc62a4b4de3d9904255a1233ae4e llvm-svn: 356351
* [TableGen] Allow 2^63-1 and 2^63-2 as int literals.Simon Tatham2019-03-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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/+40
| | | | | | | | | | | | | | | | | | | 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
* [Tablegen] Add support for the !mul operator.Nicola Zaghen2019-03-011-0/+12
| | | | | | | | | This is a small addition to arithmetic operations that improves expressiveness of the language. Differential Revision: https://reviews.llvm.org/D58775 llvm-svn: 355187
* Add support for pointer types in patternsTom Stellard2019-02-201-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for defining patterns for global isel using pointer types, for example: def : Pat<(load GPR32:$src), (p1 (LOAD GPR32:$src))>; DAGISelEmitter will ignore the pointer information and treat these types as integers with the same bit-width as the pointer type. Reviewers: dsanders, rtereshin, arsenm Reviewed By: arsenm Subscribers: Petar.Avramovic, wdng, rovka, kristof.beyls, jfb, volkan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57065 llvm-svn: 354510
* [GlobalISel] Skip patterns that define complex suboperands twice instead of ↵Jessica Paquette2019-02-091-0/+45
| | | | | | | | | | | | | | | | | | | dying If we run into a pattern that looks like this: add (complex $x, $y) (complex $x, $z) We should skip the pattern instead of asserting/doing something unpredictable. This makes us return an Error in that case, and adds a testcase for skipped patterns. Differential Revision: https://reviews.llvm.org/D57980 llvm-svn: 353586
* [TblGen] Extend !if semantics through new feature !condJaved Absar2019-01-2510-0/+224
| | | | | | | | | | | | | | | | | 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
* [tblgen][disasm] Emit record names again when decoder conflicts occur.Daniel Sanders2019-01-031-0/+35
| | | | | | And add a test for it. llvm-svn: 350277
* [TableGen] Preserve order of output operands in DAGISelMatcherGenCraig Topper2018-12-051-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes support in DAGISelMatcher backend for DAG nodes with multiple result values. Previously the order of results in selected DAG nodes always matched the order of results in ISel patterns. After the change the order of results matches the order of operands in OutOperandList instead. For example, given this definition from the attached test case: def INSTR : Instruction { let OutOperandList = (outs GPR:$r1, GPR:$r0); let InOperandList = (ins GPR:$t0, GPR:$t1); let Pattern = [(set i32:$r0, i32:$r1, (udivrem i32:$t0, i32:$t1))]; } the DAGISelMatcher backend currently produces a matcher that creates INSTR nodes with the first result `$r0` and the second result `$r1`, contrary to the order in the OutOperandList. The order of operands in OutOperandList does not matter at all, which is unexpected (and unfortunate) because the order of results of a DAG node does matters, perhaps a lot. With this change, if the order in OutOperandList does not match the order in Pattern, DAGISelMatcherGen emits CompleteMatch opcodes with the order of results taken from OutOperandList. Backend writers can use it to express result reorderings in TableGen. If the order in OutOperandList matches the order in Pattern, the result of DAGISelMatcherGen is unaffected. Patch by Eugene Sharygin Reviewers: andreadb, bjope, hfinkel, RKSimon, craig.topper Reviewed By: craig.topper Subscribers: nhaehnle, craig.topper, llvm-commits Differential Revision: https://reviews.llvm.org/D55055 llvm-svn: 348326
* [TableGen] Examine entire subreg compositions to detect ambiguityKrzysztof Parzyszek2018-11-291-0/+92
| | | | | | | | | | | | | | | | When tablegen detects that there exist two subregister compositions that result in the same value for some register, it will emit a warning. This kind of an overlap in compositions should only happen when it is caused by a user-defined composition. It can happen, however, that the user- defined composition is not identically equal to another one, but it does produce the same value for one or more registers. In such cases suppress the warning. This patch is to silence the warning when building the System Z backend after D50725. Differential Revision: https://reviews.llvm.org/D50977 llvm-svn: 347894
* [TableGen] Better error checking for TIED_TO constraints.Simon Tatham2018-11-288-0/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are quite strong constraints on how you can use the TIED_TO constraint between MC operands, many of which are currently not checked until compiler run time. MachineVerifier enforces that operands can only be tied together in pairs (no three-way ties), and MachineInstr::tieOperands enforces that one of the tied operands must be an output operand (def) and the other must be an input operand (use). Now we check these at TableGen time, so that if you violate any of them in a new instruction definition, you find out immediately, instead of having to wait until you compile something that makes code generation hit one of those assertions. Also in this commit, all the error reports in ParseConstraint now include the name and source location of the def where the problem happened, so that if you do trigger any of these errors, it's easier to find the part of your TableGen input where you made the mistake. The trunk sources already build successfully with this additional error check, so I think no in-tree target has any of these problems. Reviewers: fhahn, lhames, nhaehnle, MatzeB Reviewed By: MatzeB Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53815 llvm-svn: 347743
* [TableGen] Preprocessing supportVyacheslav Zakharin2018-11-2722-0/+307
| | | | | | Differential Revision: https://reviews.llvm.org/D54926 llvm-svn: 347686
* Reverted r347092 due to the following build fails:Vyacheslav Zakharin2018-11-1722-307/+0
| | | | | | | 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-1622-0/+307
| | | | | | Differential Revision: https://reviews.llvm.org/D53840 llvm-svn: 347092
* [TableGen] fix assert in !cast when used out of definition in a multiclassValery Pykhtin2018-10-101-0/+23
| | | | | | Differential Revision: https://reviews.llvm.org/D53068 llvm-svn: 344134
* [globalisel][tblgen] Table optimization should consider the C++ code in C++ ↵Daniel Sanders2018-09-251-0/+45
| | | | | | | | predicates This fixes PR39045 llvm-svn: 342997
* [lit, python] Always add quotes around the python path in litStella Stamenova2018-08-061-1/+1
| | | | | | | | | | | | | | | | | 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: 339073
* [GISel]: Add Opcodes for CTLZ/CTTZ/CTPOPAditya Nandakumar2018-08-043-17/+17
| | | | | | | | https://reviews.llvm.org/D48600 Added IRTranslator support to translate these known intrinsics into GISel opcodes. llvm-svn: 338944
* [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
OpenPOWER on IntegriCloud