summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenDAGPatterns.h
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Print more helpful information in case of type contradictionKrzysztof Parzyszek2017-12-211-3/+8
| | | | | | Dump the failing TreePattern. llvm-svn: 321282
* TableGen: Allow setting SDNodeProperties on intrinsicsMatt Arsenault2017-12-201-0/+2
| | | | | | | | | | | | | | | | | Allows preserving MachineMemOperands on intrinsics through selection. For reasons I don't understand, this is a static property of the pattern and the selector deliberately goes out of its way to drop if not present. Intrinsics already inherit from SDPatternOperator allowing them to be used directly in instruction patterns. SDPatternOperator has a list of SDNodeProperty, but you currently can't set them on the intrinsic. Without SDNPMemOperand, when the node is selected any memory operands are always dropped. Allowing setting this on the intrinsics avoids needing to introduce another equivalent target node just to have SDNPMemOperand set. llvm-svn: 321212
* [globalisel][tablegen] Add support for relative AtomicOrderingsDaniel Sanders2017-11-301-0/+10
| | | | | | | No test yet because the relevant rules are blocked on the atomic_load, and atomic_store nodes. llvm-svn: 319475
* [tablegen] Handle atomic predicates for ordering inside tablegen. NFC.Daniel Sanders2017-11-131-0/+11
| | | | | | | | | | | | | | | | Similar to r315841, GlobalISel and SelectionDAG require different code for the common atomic predicates due to differences in the representation. Even without that, differences in the IR (SDNode vs MachineInstr) require differences in the C++ predicate. This patch moves the implementation of the common atomic predicates related to ordering into tablegen so that it can handle these differences. It's NFC for SelectionDAG since it emits equivalent code and it's NFC for GlobalISel since the rules involving the relevant predicates are still rejected by the importer. llvm-svn: 318102
* [tablegen] Handle atomic predicates for memory type inside tablegen. NFC.Daniel Sanders2017-11-131-0/+2
| | | | | | | | | | | | | | | | Similar to r315841, GlobalISel and SelectionDAG require different code for the common atomic predicates due to differences in the representation. Even without that, differences in the IR (SDNode vs MachineInstr) require differences in the C++ predicate. This patch moves the implementation of the common atomic predicates related to memory type into tablegen so that it can handle these differences. It's NFC for SelectionDAG since it emits equivalent code and it's NFC for GlobalISel since the rules involving the relevant predicates are still rejected by the importer. llvm-svn: 318095
* [globalisel][tablegen] Import signextload and zeroextload.Daniel Sanders2017-11-111-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow a pattern rewriter to be installed in CodeGenDAGPatterns and use it to correct situations where SelectionDAG and GlobalISel disagree on representation. For example, it would rewrite: (sextload:i32 $ptr)<<unindexedload>><<sextload>><<sextloadi16> to: (sext:i32 (load:i16 $ptr)<<unindexedload>>) I'd have preferred to replace the fragments and have the expansion happen naturally as part of PatFrag expansion but the type inferencing system can't cope with loads of types narrower than those mentioned in register classes. This is because the SDTCisInt's on the sext constrain both the result and operand to the 'legal' integer types (where legal is defined as 'a register class can contain the type') which immediately rules the narrower types out. Several targets (those with only one legal integer type) would then go on to crash on the SDTCisOpSmallerThanOp<> when it removes all the possible types for the result of the extend. Also, improve isObviouslySafeToFold() slightly to automatically return true for neighbouring instructions. There can't be any re-ordering problems if re-ordering isn't happenning. We'll need to improve it further to handle sign/zero-extending loads when the extend and load aren't immediate neighbours though. llvm-svn: 317971
* [tablegen] Use hasPredCode()/hasImmCode() instead of ↵Daniel Sanders2017-10-151-1/+3
| | | | | | | | getPredCode().empty()/getImmCode().empty(). NFC These are cheaper ways of testing for the presence of code than generating the C++ code and testing it's empty. llvm-svn: 315872
* [tablegen] Handle common load/store predicates inside tablegen. NFC.Daniel Sanders2017-10-151-4/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GlobalISel and SelectionDAG require different code for the common load/store predicates due to differences in the representation. For example: SelectionDAG: (load<signext,i8>:i32 GPR32:$addr) // The <> denote properties of the SDNode that are not printed in the DAG GlobalISel: (G_SEXT:s32 (G_LOAD:s8 GPR32:$addr)) Even without that, differences in the IR (SDNode vs MachineInstr) require differences in the C++ predicate. This patch moves the implementation of the common load/store predicates into tablegen so that it can handle these differences. It's NFC for SelectionDAG since it emits equivalent code and it's NFC for GlobalISel since the rules involving the relevant predicates are still rejected by the importer. Depends on D36618 Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Subscribers: llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D37443 Includes a partial revert of r315826 since this patch makes it necessary for getPredCode() to return a std::string and getImmCode() should have the same interface as getPredCode(). llvm-svn: 315841
* [TableGen] Avoid unnecessary std::string creationsSimon Pilgrim2017-10-141-7/+6
| | | | | | Avoid unnecessary std::string creations in the TreePredicateFn getters. llvm-svn: 315826
* [globalisel][tablegen] Add support for fpimm and import of APInt/APFloat ↵Daniel Sanders2017-10-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | based ImmLeaf. Summary: There's only a tablegen testcase for IntImmLeaf and not a CodeGen one because the relevant rules are rejected for other reasons at the moment. On AArch64, it's because there's an SDNodeXForm attached to the operand. On X86, it's because the rule either emits multiple instructions or has another predicate using PatFrag which cannot easily be supported at the same time. Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar Reviewed By: qcolombet Subscribers: aemerson, javed.absar, igorb, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D36569 llvm-svn: 315761
* [aarch64] Support APInt and APFloat in ImmLeaf subclasses and make AArch64 ↵Daniel Sanders2017-10-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use them. Summary: The purpose of this patch is to expose more information about ImmLeaf-like PatLeaf's so that GlobalISel can learn to import them. Previously, ImmLeaf could only be used to test int64_t's produced by sign-extending an APInt. Other tests on immediates had to use the generic PatLeaf and extract the constant using C++. With this patch, tablegen will know how to generate predicates for APInt, and APFloat. This will allow it to 'do the right thing' for both SelectionDAG and GlobalISel which require different methods of extracting the immediate from the IR. This is NFC for SelectionDAG since the new code is equivalent to the previous code. It's also NFC for FastISel because FastIselShouldIgnore is 1 for the ImmLeaf subclasses. Enabling FastIselShouldIgnore == 0 for these new subclasses will require a significant re-factor of FastISel. For GlobalISel, it's currently NFC because the relevant code to import the affected rules is not yet present. This will be added in a later patch. Depends on D36086 Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar Reviewed By: qcolombet Subscribers: bjope, aemerson, rengolin, javed.absar, igorb, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D36534 llvm-svn: 315747
* Revert r315148 [TableGen] Avoid unnecessary std::string creationsDaniel Sanders2017-10-131-5/+5
| | | | | | | | I'm about to commit a patch that makes them necessary for getPredCode() and it would be strange for getPredCode() and getImmCode() to require different usage. llvm-svn: 315733
* [TableGen] Avoid repeated find calls in CodeGenDAGPatterns getters. NFCI.Simon Pilgrim2017-10-071-14/+21
| | | | | | | | The assertion tests were using count() instead of testing the find result, resulting in double the number of searches in debug/assert builds. Instead, call find once (like the release builds do) and assert the result against end(). llvm-svn: 315151
* [TableGen] Avoid unnecessary std::string creationsSimon Pilgrim2017-10-071-5/+5
| | | | | | | | Avoid unnecessary std::string creations in the TreePredicateFn getters and in CodeGenDAGPatterns::getSDNodeNamed Differential Revision: https://reviews.llvm.org/D38624 llvm-svn: 315148
* [TableGen] Replace InfoByHwMode::getAsString with writeToStreamKrzysztof Parzyszek2017-09-221-0/+2
| | | | | | | | | | Also add operator<< for use with raw_ostream to InfoByHwMode and its derived classes. Recommitting r313989 with the fix for unresolved references: explicitly define the operator<< in namespace llvm. llvm-svn: 314004
* Remove trailing whitespace. NFCI.Simon Pilgrim2017-09-221-11/+11
| | | | llvm-svn: 313996
* Revert "[TableGen] Replace InfoByHwMode::getAsString with writeToStream"Krzysztof Parzyszek2017-09-221-2/+0
| | | | | | This reverts commit r313989: it breaks Windows bots. llvm-svn: 313990
* [TableGen] Replace InfoByHwMode::getAsString with writeToStreamKrzysztof Parzyszek2017-09-221-0/+2
| | | | | | | Also add operator<< for use with raw_ostream to InfoByHwMode and its derived classes. llvm-svn: 313989
* [TableGen] Use CHAR_BIT instead of hardcoded 8 with sizeof. NFCCraig Topper2017-09-211-1/+1
| | | | llvm-svn: 313860
* [TableGen] Some optimizations to TableGen.Zachary Turner2017-09-201-5/+6
| | | | | | | | | This changes some STL data types to corresponding LLVM data types that have better performance characteristics. Differential Revision: https://reviews.llvm.org/D37957 llvm-svn: 313783
* Recommit r313647 now that GCC seems to accept the offeringKrzysztof Parzyszek2017-09-191-14/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some member types to MachineValueTypeSet::const_iterator so that iterator_traits can work with it. Improve TableGen performance of -gen-dag-isel (motivated by X86 backend) The introduction of parameterized register classes in r313271 caused the matcher generation code in TableGen to run much slower, particularly so in the unoptimized (debug) build. This patch recovers some of the lost performance. Summary of changes: - Cache the set of legal types in TypeInfer::getLegalTypes. The contents of this set do not change. - Add LLVM_ATTRIBUTE_ALWAYS_INLINE to several small functions. Normally this would not be necessary, but in the debug build TableGen is not optimized, so this helps a little bit. - Add an early exit from TypeSetByHwMode::operator== for the case when one or both arguments are "simple", i.e. only have one mode. This saves some time in GenerateVariants. - Finally, replace the underlying storage type in TypeSetByHwMode::SetType with MachineValueTypeSet based on std::array instead of std::set. This significantly reduces the number of memory allocation calls. I've done a number of experiments with the underlying type of InfoByHwMode. The type is a map, and for targets that do not use the parameterization, this map has only one entry. The best (unoptimized) performance, somewhat surprisingly came from std::map, followed closely by std::unordered_map. DenseMap was the slowest by a large margin. Various hand-crafted solutions (emulating enough of the map interface not to make sweeping changes to the users) did not yield any observable improvements. llvm-svn: 313660
* Revert "Improve TableGen performance of -gen-dag-isel (motivated by X86 ↵Krzysztof Parzyszek2017-09-191-158/+14
| | | | | | | | backend)" It breaks a lot of bots due to missing "__iterator_category". llvm-svn: 313651
* Improve TableGen performance of -gen-dag-isel (motivated by X86 backend)Krzysztof Parzyszek2017-09-191-14/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The introduction of parameterized register classes in r313271 caused the matcher generation code in TableGen to run much slower, particularly so in the unoptimized (debug) build. This patch recovers some of the lost performance. Summary of changes: - Cache the set of legal types in TypeInfer::getLegalTypes. The contents of this set do not change. - Add LLVM_ATTRIBUTE_ALWAYS_INLINE to several small functions. Normally this would not be necessary, but in the debug build TableGen is not optimized, so this helps a little bit. - Add an early exit from TypeSetByHwMode::operator== for the case when one or both arguments are "simple", i.e. only have one mode. This saves some time in GenerateVariants. - Finally, replace the underlying storage type in TypeSetByHwMode::SetType with MachineValueTypeSet based on std::array instead of std::set. This significantly reduces the number of memory allocation calls. I've done a number of experiments with the underlying type of InfoByHwMode. The type is a map, and for targets that do not use the parameterization, this map has only one entry. The best (unoptimized) performance, somewhat surprisingly came from std::map, followed closely by std::unordered_map. DenseMap was the slowest by a large margin. Various hand-crafted solutions (emulating enough of the map interface not to make sweeping changes to the users) did not yield any observable improvements. llvm-svn: 313647
* TableGen support for parameterized register class informationKrzysztof Parzyszek2017-09-141-179/+289
| | | | | | | | | | | | | | | | | | | | | | | | | This replaces TableGen's type inference to operate on parameterized types instead of MVTs, and as a consequence, some interfaces have changed: - Uses of MVTs are replaced by ValueTypeByHwMode. - EEVT::TypeSet is replaced by TypeSetByHwMode. This affects the way that types and type sets are printed, and the tests relying on that have been updated. There are certain users of the inferred types outside of TableGen itself, namely FastISel and GlobalISel. For those users, the way that the types are accessed have changed. For typical scenarios, these replacements can be used: - TreePatternNode::getType(ResNo) -> getSimpleType(ResNo) - TreePatternNode::hasTypeSet(ResNo) -> hasConcreteType(ResNo) - TypeSet::isConcrete -> TypeSetByHwMode::isValueTypeByHwMode(false) For more information, please refer to the review page. Differential Revision: https://reviews.llvm.org/D31951 llvm-svn: 313271
* Formatting changes, add LLVM_DUMP_METHOD to a dump function, NFCKrzysztof Parzyszek2017-09-121-1/+2
| | | | llvm-svn: 313037
* [TableGen] Remove some copies around PatternToMatch.Craig Topper2017-06-251-6/+6
| | | | | | | | | | | | | | | | | | | Summary: This patch does a few things that should remove some copies around PatternsToMatch. These were noticed while reviewing code for D34341. Change constructor to take Dstregs by value and move it into the class. Change one of the callers to add std::move to the argument so that it gets moved. Make AddPatternToMatch take PatternToMatch by rvalue reference so we can move it into the PatternsToMatch vector. I believe we should have a implicit default move constructor available on PatternToMatch. I chose rvalue reference because both callers call it with temporaries already. Reviewers: RKSimon, aymanmus, spatel Reviewed By: aymanmus Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34411 llvm-svn: 306251
* [TableGen] Adapt more places to getValueAsString now returning a StringRef ↵Craig Topper2017-05-311-4/+4
| | | | | | instead of a std::string. llvm-svn: 304347
* [SelectionDAG] Enhance SDTCisSameNumEltsAs to work with scalar types and use ↵Craig Topper2017-03-131-3/+4
| | | | | | | | | | | | it on extend/trunc/round operations. Currently we don't enforce that ISD::ANY_EXTEND, ZERO_EXTEND, SIGN_EXTEND, TRUNC, FP_ROUND, FP_EXTEND have the same number of elements(including scalar) between their input and output. Though we have them documented as such. Up until a few months ago x86 created nodes that violated this rule. That's all been fixed now, and we should enforce the rule going forward. In order to do this we need to allow SDTCisSameNumEltsAs to support scalar types and not enforce being a vector. If one type is scalar we will force the other type to also be scalar. Differential Revision: https://reviews.llvm.org/D30878 llvm-svn: 297648
* [GlobalISel] Add basic Selector-emitter tblgen backend.Ahmed Bougacha2016-12-211-0/+2
| | | | | | | | | | | | | | | | | This adds a basic tablegen backend that analyzes the SelectionDAG patterns to find simple ones that are eligible for GlobalISel-emission. That's similar to FastISel, with one notable difference: we're not fed ISD opcodes, so we need to map the SDNode operators to generic opcodes. That's done using GINodeEquiv in TargetGlobalISel.td. Otherwise, this is mostly boilerplate, and lots of filtering of any kind of "complicated" pattern. On AArch64, this is sufficient to match G_ADD up to s64 (to ADDWrr/ADDXrr) and G_BR (to B). Differential Revision: https://reviews.llvm.org/D26878 llvm-svn: 290284
* Use the range variant of find instead of unpacking begin/endDavid Majnemer2016-08-111-2/+1
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278433
* IR: Sort generic intrinsics before target specific onesJustin Bogner2016-07-151-2/+2
| | | | | | | | | | | | This splits out the intrinsic table such that generic intrinsics come first and target specific intrinsics are grouped by target. From here we can find out which target an intrinsic is for or differentiate between generic and target intrinsics. The motivation here is to make it easier to move target specific intrinsic handling out of generic code. llvm-svn: 275575
* [SelectionDAG] Add a SDTCisSameSizeAs type constraint that can be used to ↵Craig Topper2015-11-261-1/+7
| | | | | | ensure vector widths match even if the element size and count don't. llvm-svn: 254138
* Fix typos.Bruce Mitchener2015-09-121-4/+4
| | | | | | | | | | Summary: This fixes a variety of typos in docs, code and headers. Subscribers: jholewinski, sanjoy, arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12626 llvm-svn: 247495
* [TableGen] Add support constraining a vector type in a pattern to have a ↵Craig Topper2015-03-051-1/+15
| | | | | | specific element type and for constraining a vector type to have the same number of elements as another vector type. This is useful for AVX512 mask operations so we relate the mask type to the type of the other arguments. llvm-svn: 231356
* Revert "Improve memory ownership/management in TableGen by unique_ptrifying ↵David Blaikie2014-11-171-19/+13
| | | | | | | | | | | | TreePattern's Tree member." This reverts commit r222183. Broke on the MSVC buildbots due to MSVC not producing default move operations - I'd fix it immediately but just broke my build system a bit, so backing out until I have a chance to get everything going again. llvm-svn: 222187
* Improve memory ownership/management in TableGen by unique_ptrifying ↵David Blaikie2014-11-171-13/+19
| | | | | | | | | | | | TreePattern's Tree member. The next step is to actually use unique_ptr in TreePatternNode's Children vector. That will be more intrusive, and may not work, depending on exactly how these things are handled (I have a bad suspicion things are shared more than they should be, making this more DAG than tree - but if it's really a tree, unique_ptr should suffice) llvm-svn: 222183
* Fix nested namespace with decltype to hopefully work with MSVCDavid Blaikie2014-11-131-1/+2
| | | | | | | | | | Build failed here: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/14629/steps/build_Lld/logs/stdio So I'm taking a shot in the dark that MSVC (whatever version that is) can't cope with nested name specifiers with a decltype prefix. llvm-svn: 221931
* Use unique_ptr to handle ownership of TreePatterns in ↵David Blaikie2014-11-131-7/+7
| | | | | | | | | CodeGenDAGPatterns::PatternFragments We might be able to use unique_ptr to handle ownership of the TreePatternNodes too - looking into that next. llvm-svn: 221928
* Make TreePattern::error use TwineMatt Arsenault2014-11-111-1/+1
| | | | | | | The underlying error function already uses a Twine, and most of the uses build up strings. llvm-svn: 221740
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* TableGen: Allow AddedComplexity values to be negativeTom Stellard2014-08-011-4/+4
| | | | | | | | | | | | | This is useful for cases when stand-alone patterns are preferred to the patterns included in the instruction definitions. Instead of requiring that stand-alone patterns set a larger AddedComplexity value, which can be confusing to new developers, the allows us to reduce the complexity of the included patterns to achieve the same result. There will be test cases for this added to the R600 backend in a future commit. llvm-svn: 214466
* Revert of r213521. This change introduced a non-hermetic test (depending on aRichard Smith2014-07-221-4/+4
| | | | | | | | | | file not in the test/ area). Backing out now so that this test isn't part of the 3.5 branch. Original commit message: "TableGen: Allow AddedComplexity values to be negative [...]" llvm-svn: 213596
* TableGen: Allow AddedComplexity values to be negativeTom Stellard2014-07-211-4/+4
| | | | | | | | | | This is useful for cases when stand-alone patterns are preferred to the patterns included in the instruction definitions. Instead of requiring that stand-alone patterns set a larger AddedComplexity value, which can be confusing to new developers, the allows us to reduce the complexity of the included patterns to achieve the same result. llvm-svn: 213521
* TableGen: permit non-leaf ComplexPattern usesTim Northover2014-05-201-0/+13
| | | | | | | | | | | | | | | | | | This allows the results of a ComplexPattern check to be distributed to separate named Operands, instead of the current system where all results must apply (and match perfectly) with a single Operand. For example, if "some_addrmode" is a ComplexPattern producing two results, you can write: def : Pat<(load (some_addrmode GPR64:$base, imm:$offset)), (INST GPR64:$base, imm:$offset)>; This should allow neater instruction definitions in TableGen that don't put all possible aspects of addressing into a single operand, but are still usable with relatively simple C++ CodeGen idioms. llvm-svn: 209206
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-161-8/+8
| | | | | | instead of comparing to nullptr. llvm-svn: 206356
* Add an OutPatFrag TableGen classHal Finkel2014-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, it is currently impossible to use a PatFrag as part of an output pattern (the part of the pattern that has instructions in it) in TableGen. Looking at the current implementation, this was clearly intended to work (there is already code in place to expand patterns in the output DAG), but is currently broken by the baked-in type-checking assumption and the order in which the pattern fragments are processed (output pattern fragments need to be processed after the instruction definitions are processed). Fixing this is fairly simple, but requires some way of differentiating output patterns from the existing input patterns. The simplest way to handle this seems to be to create a subclass of PatFrag, and so that's what I've done here. As a simple example, this allows us to write: def crnot : OutPatFrag<(ops node:$in), (CRNOR $in, $in)>; def : Pat<(not i1:$in), (crnot $in)>; which captures the core use case: handling of repeated subexpressions inside of complicated output patterns. This will be used by an upcoming commit to the PowerPC backend. llvm-svn: 202450
* Improve handling of EnforceSmallerThan. Remove all types that are smaller ↵Craig Topper2014-01-281-0/+4
| | | | | | from the larger set not just the smallest type from the smaller set. Ensure 'smaller' vectors have the same or fewer total bits. Similar for 'larger' vectors. llvm-svn: 200287
* TableGen: Refactor DAG patterns to enable parsing one pattern at a time.Ahmed Bougacha2013-10-281-1/+5
| | | | llvm-svn: 193526
* Make all unnamed RegisterClass TreePatternNodes typed MVT::i32.Jakob Stoklund Olesen2013-03-231-0/+1
| | | | | | | | | | | | | | | | | | | | | A register class can appear as a leaf TreePatternNode with and without a name: (COPY_TO_REGCLASS GPR:$src, F8RC) In a named leaf node like GPR:$src, the register class provides type information for the named variable represented by the node. The TypeSet for such a node is the set of value types that the register class can represent. In an unnamed leaf node like F8RC above, the register class represents itself as a kind of immediate. Such a node has the type MVT::i32, we'll never create a virtual register representing it. This change makes it possible to remove the special handling of COPY_TO_REGCLASS in CodeGenDAGPatterns.cpp. llvm-svn: 177825
* Extract a method.Jakob Stoklund Olesen2013-03-181-0/+5
| | | | | | | This computes the type of an instruction operand or result based on the records in the instruction's ins and outs lists. llvm-svn: 177244
OpenPOWER on IntegriCloud