summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenDAGPatterns.h
Commit message (Collapse)AuthorAgeFilesLines
* TableGen: Remove unused codeMatt Arsenault2020-01-091-6/+0
|
* [TableGen] Remove unused target intrinsic generation logicReid Kleckner2019-12-111-9/+0
| | | | | | | | | | | | AMDGPU was the last in tree target to use this tablegen mode. I plan to split up the global intrinsic enum similar to the way that clang diagnostics are split up today. I don't plan to build on this mode. Reviewers: arsenm, echristo, efriedma Reviewed By: echristo Differential Revision: https://reviews.llvm.org/D71318
* Reland 'Fixed -Wdeprecated-copy warnings. NFCI.'Dávid Bolvanský2019-11-231-0/+1
| | | | Fixed hashtable copy ctor.
* Revert 'Fixed -Wdeprecated-copy warnings. NFCI.'Dávid Bolvanský2019-11-231-1/+0
| | | | pdbutil's test is failing.
* Fixed -Wdeprecated-copy warnings. NFCI.Dávid Bolvanský2019-11-231-0/+1
|
* TableGen: Add MinAlignment predicateMatt Arsenault2019-07-311-0/+1
| | | | | | | | | | 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
* AMDGPU: Avoid emitting "true" predicatesMatt Arsenault2019-07-301-0/+3
| | | | | | | | | | Empty condition strings are considerde always true. This removes a lot of clutter from the generated matcher tables. This shrinks the source size of AMDGPUGenDAGISel.inc from 7.3M to 6.1M. llvm-svn: 367326
* TableGen: Add address space to matchersMatt Arsenault2019-07-151-0/+2
| | | | | | | | | | | | | | | | | 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
* [TableGen] Allow DAG isel patterns to override default operands.Simon Tatham2019-07-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support for pointer types in patternsTom Stellard2019-02-201-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud