aboutsummaryrefslogtreecommitdiff
path: root/llvm/utils/TableGen/CodeGenDAGPatterns.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-12-21[TableGen] Print more helpful information in case of type contradictionKrzysztof Parzyszek1-18/+31
Dump the failing TreePattern. llvm-svn: 321282
2017-12-20TableGen: Allow setting SDNodeProperties on intrinsicsMatt Arsenault1-33/+12
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
2017-11-30[globalisel][tablegen] Add support for relative AtomicOrderingsDaniel Sanders1-1/+40
No test yet because the relevant rules are blocked on the atomic_load, and atomic_store nodes. llvm-svn: 319475
2017-11-13[tablegen] Handle atomic predicates for ordering inside tablegen. NFC.Daniel Sanders1-1/+53
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
2017-11-13[tablegen] Handle atomic predicates for memory type inside tablegen. NFC.Daniel Sanders1-12/+31
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
2017-11-11[globalisel][tablegen] Import signextload and zeroextload.Daniel Sanders1-2/+8
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
2017-11-07[AArch64][SVE] Asm: Extend EnforceVectorSubVectorTypeIs to distinguish ↵Florian Hahn1-0/+5
Scalable Vectors Patch [1/5] in a series to add assembler/disassembler support for AArch64 SVE unpredicated ADD/SUB instructions. Patch by Sander De Smalen. Reviewed by: rengolin Differential Revision: https://reviews.llvm.org/D39087 llvm-svn: 317564
2017-10-15[tablegen] Use hasPredCode()/hasImmCode() instead of ↵Daniel Sanders1-4/+14
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
2017-10-15[TableGen] Remove error checks incorrectly failing on non-error conditionsKrzysztof Parzyszek1-49/+6
In type inference, an empty type set for a specific hw mode is not an error. In earlier stages of the design it was, but having to use non- parameterized types with target intrinsics necessarily led to type contradictions: since the intrinsics used specific types, they were only valid for a specific hw mode, and the resulting type set for other modes ended up empty. To accommodate the existence of such intrinsics individual type sets were allowed to be empty as long as not all sets were empty. llvm-svn: 315858
2017-10-15[tablegen] Handle common load/store predicates inside tablegen. NFC.Daniel Sanders1-7/+216
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
2017-10-14[TableGen] Avoid unnecessary std::string creationsSimon Pilgrim1-10/+10
Avoid unnecessary std::string creations in the TreePredicateFn getters. llvm-svn: 315826
2017-10-13[globalisel][tablegen] Add support for fpimm and import of APInt/APFloat ↵Daniel Sanders1-0/+8
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
2017-10-13[aarch64] Support APInt and APFloat in ImmLeaf subclasses and make AArch64 ↵Daniel Sanders1-2/+25
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
2017-10-13Revert r315148 [TableGen] Avoid unnecessary std::string creationsDaniel Sanders1-8/+8
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
2017-10-07[TableGen] Avoid unnecessary std::string creationsSimon Pilgrim1-8/+8
Avoid unnecessary std::string creations in the TreePredicateFn getters and in CodeGenDAGPatterns::getSDNodeNamed Differential Revision: https://reviews.llvm.org/D38624 llvm-svn: 315148
2017-09-27Use const where possible. NFCI.Simon Pilgrim1-1/+1
llvm-svn: 314292
2017-09-26Tidyup P->getComplexPatternInfo call by moving it inside if( != NULL) test. ↵Simon Pilgrim1-3/+1
NFCI. llvm-svn: 314202
2017-09-22[TableGen] Replace InfoByHwMode::getAsString with writeToStreamKrzysztof Parzyszek1-2/+8
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
2017-09-22Remove trailing whitespace. NFCI.Simon Pilgrim1-2/+2
llvm-svn: 313996
2017-09-22Revert "[TableGen] Replace InfoByHwMode::getAsString with writeToStream"Krzysztof Parzyszek1-6/+2
This reverts commit r313989: it breaks Windows bots. llvm-svn: 313990
2017-09-22[TableGen] Replace InfoByHwMode::getAsString with writeToStreamKrzysztof Parzyszek1-2/+6
Also add operator<< for use with raw_ostream to InfoByHwMode and its derived classes. llvm-svn: 313989
2017-09-21[TableGen] Include StringMap.h instead of StringSet.h since that's the data ↵Craig Topper1-1/+1
structure we use. llvm-svn: 313859
2017-09-20[TableGen] Some optimizations to TableGen.Zachary Turner1-39/+46
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
2017-09-19Recommit r313647 now that GCC seems to accept the offeringKrzysztof Parzyszek1-28/+52
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
2017-09-19Revert "Improve TableGen performance of -gen-dag-isel (motivated by X86 ↵Krzysztof Parzyszek1-52/+28
backend)" It breaks a lot of bots due to missing "__iterator_category". llvm-svn: 313651
2017-09-19Improve TableGen performance of -gen-dag-isel (motivated by X86 backend)Krzysztof Parzyszek1-28/+52
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
2017-09-17Remove uses of deprecated std::not1.Benjamin Kramer1-3/+3
Lambdas are slightly more verbose, but also more readable. No functionality change intended. llvm-svn: 313482
2017-09-15Fix selecting legal types in TypeInfer::getLegalTypesKrzysztof Parzyszek1-9/+3
Collect all legal types for all modes. llvm-svn: 313380
2017-09-14TableGen support for parameterized register class informationKrzysztof Parzyszek1-729/+1017
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
2017-09-14[tblgen] Remove uses of std::ptr_fun, it's removed in C++17.Benjamin Kramer1-8/+5
No functionality change intended. llvm-svn: 313269
2017-09-12Remove ancient, commented out code from TableGen, NFCKrzysztof Parzyszek1-12/+0
These pieces were commented out in r98534 and r129691, i.e. 6+ years ago. llvm-svn: 313038
2017-09-12Formatting changes, add LLVM_DUMP_METHOD to a dump function, NFCKrzysztof Parzyszek1-5/+4
llvm-svn: 313037
2017-09-04[TableGen] Teach tablegen to allow SDNPCommutable nodes with more than 2 ↵Craig Topper1-4/+9
operands. Summary: Tablegen already supports commutable instrinsics with more than 2 operands. There it just assumes the first two operands are commutable. I plan to use this to improve the generation of FMA patterns in the X86 backend. Reviewers: aymanmus, zvi, RKSimon, spatel, arsenm Reviewed By: arsenm Subscribers: arsenm, llvm-commits Differential Revision: https://reviews.llvm.org/D37430 llvm-svn: 312464
2017-08-30[TableGen] Fix a range based for loop to take the value by reference so that ↵Craig Topper1-1/+1
SimplifyTree can modify the copy in the array if its needs to. llvm-svn: 312088
2017-06-27[TableGen] Fix bug in TableGen CodeGenPatterns when adding variants of the ↵Ayman Musa1-2/+2
patterns. All patterns reside in a std::vector container, where new variants are added to it using the standard library's emplace_back function. When calling this with a new element while there is no enough allocated space, a bigger space is allocated and all the old info in the small vector is copied to the newly allocated vector, then the old vector is freed. The problem is that before doing this "copying", we take a reference of one of the elements in the old vector, and after the "copying" we add it to the new vector. As the old vector is freed after the copying, the reference now does not point to a valid element. Added new function to the API of CodeGenDAGPatterns class to return the same information as a copy in order to avoid this issue. This was revealed in rL305465 that added many patterns and forced the reallocation of the vector which caused crashes in windows bots. Differential Revision: https://reviews.llvm.org/D34341 llvm-svn: 306371
2017-06-25[TableGen] Remove some copies around PatternToMatch.Craig Topper1-10/+8
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
2017-06-20[TableGen] Take a parameter by reference instead of pointer so we don't have ↵Craig Topper1-4/+4
to add & on both callers. NFC llvm-svn: 305807
2017-06-20[TableGen] Use range based for loop. NFCCraig Topper1-3/+1
llvm-svn: 305806
2017-06-16[TableGen] Do not assume that the first variant is the original patternKrzysztof Parzyszek1-3/+1
The variant generation for commutative/associative patterns would simply delete the first output from the list assuming that it was identical to the original pattern. This does not have to be the case, and a legitimate variant could actually be removed that way. llvm-svn: 305556
2017-05-31[TableGen] Adapt more places to getValueAsString now returning a StringRef ↵Craig Topper1-1/+1
instead of a std::string. llvm-svn: 304347
2017-05-31[TableGen] Make Record::getValueAsString and getValueAsListOfStrings return ↵Craig Topper1-1/+3
StringRefs instead of std::string Internally both these methods just return the result of getValue on either a StringInit or a CodeInit object. In both cases this returns a StringRef pointing to a string allocated in the BumpPtrAllocator so its not going anywhere. So we can just pass that StringRef along. This is a fairly naive patch that targets just the build failures caused by this change. There's additional work that can be done to avoid creating std::string at call sites that still think getValueAsString returns a std::string. I'll try to clean those up in future patches. Differential Revision: https://reviews.llvm.org/D33710 llvm-svn: 304325
2017-04-28TableGen: Add IntrHasSideEffects property for intrinsicsMatt Arsenault1-1/+2
The IntrNoMem, IntrReadMem, IntrWriteMem, and IntrArgMemOnly intrinsic properties differ from their corresponding LLVM IR attributes by specifying that the intrinsic, in addition to its memory properties, has no other side effects. The IntrHasSideEffects flag used in combination with one of the memory flags listed above, makes it possible to define an intrinsic such that its properties at the CodeGen layer match its properties at the IR layer. Patch by Tom Stellard llvm-svn: 301685
2017-03-13[SelectionDAG] Enhance SDTCisSameNumEltsAs to work with scalar types and use ↵Craig Topper1-35/+53
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
2017-02-18[TableGen] Make sure EnforceSameSize populates the type sets if necessary.Craig Topper1-0/+6
This was found by another commit I'm working on. llvm-svn: 295578
2017-01-28Cleanup dump() functions.Matthias Braun1-2/+2
We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
2016-12-19[TableGen] Use 'unsigned' instead of 'bool' in a place where the code ↵Craig Topper1-1/+1
conditionally assigns numeric values. They happen to be 0 and 1 so this is NFC. llvm-svn: 290088
2016-12-05TableGen: Use StringInit instead of std::string for DagInit arg namesMatthias Braun1-9/+11
llvm-svn: 288644
2016-12-05TableGen: Use StringInit instead of std::string for DagInit nameMatthias Braun1-4/+4
llvm-svn: 288643
2016-12-04TableGen: Use StringRef instead of const std::string& in return vals.Matthias Braun1-1/+1
This will allow to switch to a different string storage in an upcoming commit. llvm-svn: 288612
2016-11-09Re-apply r286384, "X86: Introduce the "relocImm" ComplexPattern, which ↵Peter Collingbourne1-6/+1
represents a relocatable immediate.", with a fix for 32-bit x86. Teach X86InstrInfo::analyzeCompare() not to crash on CMP and SUB instructions that take a global address operand. llvm-svn: 286420
generated by cgit v1.1 at 2025-10-04 07:02:08 +0000