summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenDAGPatterns.h
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [TableGen] Preserve order of output operands in DAGISelMatcherGenCraig Topper2018-12-051-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/ISel: Allow PatFrag predicate code to access captured operandsNicolai Haehnle2018-11-301-13/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This simplifies writing predicates for pattern fragments that are automatically re-associated or commuted. For example, a followup patch adds patterns for fragments of the form (add (shl $x, $y), $z) to the AMDGPU backend. Such patterns are automatically commuted to (add $z, (shl $x, $y)), which makes it basically impossible to refer to $x, $y, and $z generically in the PredicateCode. With this change, the PredicateCode can refer to $x, $y, and $z simply as `Operands[i]`. Test confirmed that there are no changes to any of the generated files when building all (non-experimental) targets. Change-Id: I61c00ace7eed42c1d4edc4c5351174b56b77a79c Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand Subscribers: wdng, tpr, llvm-commits Differential Revision: https://reviews.llvm.org/D51994 llvm-svn: 347992
* TableGen/CodeGenDAGPatterns: addPredicateFn only onceNicolai Haehnle2018-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: The predicate function is added in InlinePatternFragments, no need to do it here. As a result, all uses of addPredicateFn are located in InlinePatternFragments. Test confirmed that there are no changes to generated files when building all (non-experimental) targets. Change-Id: I720e42e045ca596eb0aa339fb61adf6fe71034d5 Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D51993 llvm-svn: 343977
* [TableGen] TypeInfer - Cache the legal types as TypeSetByHwModeSimon Pilgrim2018-08-171-3/+3
| | | | | | | | | | | | We were just caching the MVT set of legal types, then every call creating a new TypeSetByHwMode with it and passing it back on the stack. There's no need to do this - we can create and cache the whole TypeSetByHwMode once and return a const reference to it each time. Additionally, TypeInfer::expandOverloads wasn't making use of the fact that the cache just contains a default mode containing all the types. Saves up to 30secs in debug builds of x86 -gen-dag-isel. Differential Revision: https://reviews.llvm.org/D50903 llvm-svn: 340042
* [TableGen] std::move vectors into TreePatternNode.Craig Topper2018-07-151-2/+3
| | | | llvm-svn: 337121
* [TableGen] Add some std::move to the PatternToMatch constructor.Craig Topper2018-07-151-1/+1
| | | | | | The are two vectors passed by value to the constructor. We should be able to move them into the object. llvm-svn: 337114
* [TableGen] Suppress type validation when parsing pattern fragmentsUlrich Weigand2018-07-131-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, any attempt to define a PatFrag involving any floating-point only (or vector only) node causes a hard assertion failure in TableGen if the current target does not have any floating-point (or vector) types. This is annoying if you want to provide convenience fragments in common code (e.g. include/llvm/Target/TargetSelectionDAG.td) that is parsed on all platforms, including those that miss such types. But really, there's no reason not accept this when parsing the fragment -- of course it would be an error for such a target to actually *use* such a fragment anywhere, but as long as it doesn't, I think TableGen shouldn't error out. The immediate cause of the assertion failure is the test inside the ValidateOnExit destructor. This patch simply disables that check while infering types during parsing of pattern fragments (only). Reviewed By: hfinkel, kparzysz Differential Revision: https://reviews.llvm.org/D48887 llvm-svn: 337023
* [TableGen] Support multi-alternative pattern fragmentsUlrich Weigand2018-07-131-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A TableGen instruction record usually contains a DAG pattern that will describe the SelectionDAG operation that can be implemented by this instruction. However, there will be cases where several different DAG patterns can all be implemented by the same instruction. The way to represent this today is to write additional patterns in the Pattern (or usually Pat) class that map those extra DAG patterns to the instruction. This usually also works fine. However, I've noticed cases where the current setup seems to require quite a bit of extra (and duplicated) text in the target .td files. For example, in the SystemZ back-end, there are quite a number of instructions that can implement an "add-with-overflow" operation. The same instructions also need to be used to implement just plain addition (simply ignoring the extra overflow output). The current solution requires creating extra Pat pattern for every instruction, duplicating the information about which particular add operands map best to which particular instruction. This patch enhances TableGen to support a new PatFrags class, which can be used to encapsulate multiple alternative patterns that may all match to the same instruction. It operates the same way as the existing PatFrag class, except that it accepts a list of DAG patterns to match instead of just a single one. As an example, we can now define a PatFrags to match either an "add-with-overflow" or a regular add operation: def z_sadd : PatFrags<(ops node:$src1, node:$src2), [(z_saddo node:$src1, node:$src2), (add node:$src1, node:$src2)]>; and then use this in the add instruction pattern: defm AR : BinaryRRAndK<"ar", 0x1A, 0xB9F8, z_sadd, GR32, GR32>; These SystemZ target changes are implemented here as well. Note that PatFrag is now defined as a subclass of PatFrags, which means that some users of internals of PatFrag need to be updated. (E.g. instead of using PatFrag.Fragment you now need to use !head(PatFrag.Fragments).) The implementation is based on the following main ideas: - InlinePatternFragments may now replace each original pattern with several result patterns, not just one. - parseInstructionPattern delays calling InlinePatternFragments and InferAllTypes. Instead, it extracts a single DAG match pattern from the main instruction pattern. - Processing of the DAG match pattern part of the main instruction pattern now shares most code with processing match patterns from the Pattern class. - Direct use of main instruction patterns in InferFromPattern and EmitResultInstructionAsOperand is removed; everything now operates solely on DAG match patterns. Reviewed by: hfinkel Differential Revision: https://reviews.llvm.org/D48545 llvm-svn: 336999
* [globalisel][tablegen] Add support for C++ predicates on PatFrags and use it ↵Daniel Sanders2018-06-151-0/+4
| | | | | | | | | | | | | | | | | | | | | 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
* Revert r334764, as it breaks some botsFlorian Hahn2018-06-141-8/+7
| | | | llvm-svn: 334767
* [TableGen] Make TreePatternNode::getChild return a reference (NFC)Florian Hahn2018-06-141-7/+8
| | | | | | | | The return value of TreePatternNode::getChild is never null. This patch also updates various places that use return values of getChild to also use references. Those changes were suggested post-commit for D47463. llvm-svn: 334764
* [TableGen] Make getOnlyTree return a const ref (NFC)Florian Hahn2018-06-131-1/+1
| | | | | | | This avoids some unnecessary copies of shared_ptrs. Those changes were suggested post-commit for D47463. llvm-svn: 334656
* TableGen: Change some pointer parameters to references since they're never ↵David Blaikie2018-06-111-1/+1
| | | | | | null anyway llvm-svn: 334446
* [TableGen] Combine two constructors by taking vectors by value instead of ↵Craig Topper2018-06-101-11/+3
| | | | | | trying to support combininations for rvalue and lvalue references. llvm-svn: 334379
* Revert r334374 [TableGen] Move some shared_ptrs to avoid unnecessary copies ↵Florian Hahn2018-06-101-5/+1
| | | | | | | | (NFC). This breaks some builders. llvm-svn: 334376
* [TableGen] Move some shared_ptrs to avoid unnecessary copies (NFC).Florian Hahn2018-06-101-1/+5
| | | | | | Those changes were suggested post-commit for D47463. llvm-svn: 334374
* [TableGen] Make DAGInstruction own Pattern to avoid leaking it.Florian Hahn2018-06-081-4/+4
| | | | | | | | | | Reviewers: dsanders, craig.topper, stoklund, nhaehnle Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D47525 llvm-svn: 334275
* [TableGen] Avoid leaking TreePatternNodes by using shared_ptr.Florian Hahn2018-05-301-53/+58
| | | | | | | | | | | | By using std::shared_ptr for TreePatternNode, we can avoid leaking them. Reviewers: craig.topper, dsanders, stoklund, tstellar, zturner Reviewed By: dsanders Differential Revision: https://reviews.llvm.org/D47463 llvm-svn: 333591
* [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
OpenPOWER on IntegriCloud