summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenRegisters.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [TableGen] Replace InfoByHwMode::getAsString with writeToStreamKrzysztof Parzyszek2017-09-221-1/+1
| | | | | | | | | | 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
* Revert "[TableGen] Replace InfoByHwMode::getAsString with writeToStream"Krzysztof Parzyszek2017-09-221-1/+1
| | | | | | This reverts commit r313989: it breaks Windows bots. llvm-svn: 313990
* [TableGen] Replace InfoByHwMode::getAsString with writeToStreamKrzysztof Parzyszek2017-09-221-1/+1
| | | | | | | Also add operator<< for use with raw_ostream to InfoByHwMode and its derived classes. llvm-svn: 313989
* [TableGen] Tidy up CodeGenRegistersJaved Absar2017-09-211-28/+23
| | | | | | | | | Replacing range loops. Reviewed by: @MatzeB Differential Revision: https://reviews.llvm.org/D38091 llvm-svn: 313874
* TableGen support for parameterized register class informationKrzysztof Parzyszek2017-09-141-27/+26
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Try to fix compilation problem with libstdc++Matthias Braun2017-08-281-1/+3
| | | | llvm-svn: 311918
* Address r311914 review commentsMatthias Braun2017-08-281-7/+5
| | | | llvm-svn: 311917
* TableGen: Fix subreg composition/concatenationMatthias Braun2017-08-281-27/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes 2 problems in subregister hierarchies with multiple levels and tuples: 1) For bigger tuples computing secondary subregs would miss 2nd order effects. In the test case a register like `S10_S11_S12_S13_S14` with D5 = S10_S11, D6 = S12_S13 we would correctly compute sub0 = D5, sub1 = D6 but would miss the fact that we could now form ssub0_ssub1_ssub2_ssub3 (aka sub0_sub1) = D5_D6. This is fixed by changing computeSecondarySubRegs() to compute a fixpoint. 2) Fixing 1) exposed a problem where TableGen would create multiple names for effectively the same subregister index. In the test case the subregister index sub0 is composed from ssub0 and ssub1, and sub1 is composed from ssub2 and ssub3. TableGen should not create both sub0_sub1 and ssub0_ssub1_ssub2_ssub3 as infered subregister indexes. This changes the code to build a transitive closure of the subregister components before forming new concatenated subregister indexes. This fix was developed for an out of tree target. For the in-tree targets the only change is in the register information computed for ARM. There is a slight chance this fixed/improved some register coalescing around the QQQQ/QQ register classes there but I couldn't see/provoke any code generation differences. Differential Revision: https://reviews.llvm.org/D36913 llvm-svn: 311914
* Implement LaneBitmask::getNumLanes and LaneBitmask::getHighestLaneKrzysztof Parzyszek2017-07-201-6/+2
| | | | | | | This should eliminate most uses of countPopulation and Log2_32 on the lane mask values. llvm-svn: 308658
* [TableGen][MC] Fix a few places where we didn't hide the underlying type of ↵Craig Topper2017-07-141-6/+6
| | | | | | | | | | LaneBitmask very well. One place compared with 32, which I've replaced with LaneBitmask::BitWidth. The other places are shifts of a constant 1 by a lane number. But if LaneBitmask were to be a larger type than 32-bits like 64-bits, the 1 would need to be 1ULL to do a 64-bit shift. To hide this I've added a LanebitMask::getLane that hides the shift and make sures the 1 is casted to correct type first. llvm-svn: 308042
* Change sort function used in tblgen to be strict weak orderingDavid Green2017-06-271-1/+1
| | | | | | | The windows debug is failing as the sort function is not strict weak ordering, so switch a >= to a >. llvm-svn: 306422
* [globalisel][tablegen] Add support for EXTRACT_SUBREG.Daniel Sanders2017-06-271-0/+78
| | | | | | | | | | | | | | | | Summary: After this patch, we finally have test cases that require multiple instruction emission. Depends on D33590 Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls Subscribers: javed.absar, llvm-commits, igorb Differential Revision: https://reviews.llvm.org/D33596 llvm-svn: 306388
* [TableGen] Remove code for renaming anonymous register classes as it can ↵Craig Topper2017-06-011-6/+1
| | | | | | | | never execute. It tried to detect 9 letters (the length of anonymous) followed by a period. But anonymous classes start with "anonymous_" rather than "anonymous." these days. llvm-svn: 304387
* [TableGen] Print #nnn as a name of an non-native reg unit with id nnnKrzysztof Parzyszek2017-03-271-6/+13
| | | | | | | | | When using -debug with -gen-register-info, tablegen will crash when trying to print a name of a non-native register unit. This patch only affects the debug information generated while running llvm-tblgen, and has no impact on the compilable code coming out of it. llvm-svn: 298875
* Implement LaneBitmask::any(), use it to replace !none(), NFCIKrzysztof Parzyszek2016-12-161-3/+3
| | | | llvm-svn: 289974
* Extract LaneBitmask into a separate typeKrzysztof Parzyszek2016-12-151-29/+35
| | | | | | | | | | | | Specifically avoid implicit conversions from/to integral types to avoid potential errors when changing the underlying type. For example, a typical initialization of a "full" mask was "LaneMask = ~0u", which would result in a value of 0x00000000FFFFFFFF if the type was extended to uint64_t. Differential Revision: https://reviews.llvm.org/D27454 llvm-svn: 289820
* TableGen: Use StringRef instead of const std::string& in return vals.Matthias Braun2016-12-041-1/+1
| | | | | | | This will allow to switch to a different string storage in an upcoming commit. llvm-svn: 288612
* Fix some Clang-tidy and Include What You Use warnings; other minor fixes (NFC).Eugene Zelenko2016-11-301-12/+38
| | | | | | This preparation to remove SetVector.h dependency on SmallSet.h. llvm-svn: 288256
* 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
* TableGen: Produce CoveredBySubRegs summary for register classesMatthias Braun2016-04-281-2/+5
| | | | | | This will be used in the upcoming "DetectDeadLanes" pass. llvm-svn: 267850
* TableGen: Support lanemasks for classes without subregistersMatthias Braun2016-04-281-38/+50
| | | | | | | | | | | | | Previously using lanemasks on registers without any subregisters was not well defined. This commit extends TargetRegisterInfo/tablegen to: - Report a lanemask of 1 for regclasses without subregisters - Do the right thing when mapping a 0/1 lanemask from a class without subregisters into a class with subregisters in TargetRegisterInfo::composeSubRegIndexLaneMasks(). This will be used in the upcoming "DetectDeadLanes" patch. llvm-svn: 267848
* [TableGen] Merge the SuperClass Record and SMRange vector into a single ↵Craig Topper2016-01-181-4/+3
| | | | | | vector. This removes the state needed to manage the extra vector thus reducing the size of the Record class. NFC llvm-svn: 258065
* Assume lane masks are always preciseMatthias Braun2015-11-171-13/+6
| | | | | | | | | | | | | | | Allowing imprecise lane masks in case of more than 32 sub register lanes lead to some tricky corner cases, and I need another bugfix for another one. Instead I rather declare lane masks as precise and let tablegen abort if we do not have enough bits. This does not affect any in-tree target, even AMDGPU only needs 16 lanes at the moment. If the 32 lanes turn out to be a problem in the future, then we can easily change the LaneBitmask typedef to uint64_t. Differential Revision: http://reviews.llvm.org/D14557 llvm-svn: 253279
* tablegen: Add a simple heuristic to get better names for pressure setsMatthias Braun2015-11-131-0/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D14597 llvm-svn: 253095
* TableGen: Emit LaneMask for register classes without subregisters as ~0uMatthias Braun2015-11-101-0/+6
| | | | | | | This makes it slightly easier to handle classes with and without subregister uniformly. llvm-svn: 252671
* [TableGen] Rename ListInit::getSize to just 'size' to be more consistent.Craig Topper2015-06-021-3/+3
| | | | llvm-svn: 238806
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-2/+2
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* [TableGen] Remove ListInit::size() in favor of getSize() which does the same ↵Craig Topper2015-05-141-2/+2
| | | | | | thing and is already used in most places. NFC. llvm-svn: 237341
* [TableGen] Don't leak Expanders and Operators in SetTheory.Craig Topper2015-04-241-1/+1
| | | | llvm-svn: 235697
* Change range-based for-loops to be -Wrange-loop-analysis clean.Richard Trieu2015-04-151-1/+1
| | | | | | No functionality change. llvm-svn: 234963
* Fix AllocationPriority not getting set for derived register classes.Matthias Braun2015-03-311-1/+3
| | | | llvm-svn: 233752
* RegAllocGreedy: Allow target to specify register class ordering.Matthias Braun2015-03-311-0/+4
| | | | | | | | | | Specify an allocation order with a register class. This is used by register allocators with a greedy heuristic. This is usefull as it is sometimes beneficial to color more constrained classes first. Differential Revision: http://reviews.llvm.org/D8626 llvm-svn: 233743
* Do not track subregister liveness when it brings no benefitsMatthias Braun2015-03-191-0/+11
| | | | | | | | | | | Some subregisters are only to indicate different access sizes, while not providing any way to actually divide the register up into multiple disjunct parts. Avoid tracking subregister liveness in these cases as it is not beneficial. Differential Revision: http://reviews.llvm.org/D8429 llvm-svn: 232695
* TableGen: Fix register class lane masks being too conservative.Matthias Braun2015-03-181-1/+1
| | | | | | | | | | | | | | When calculating the lanemask of a register class we have to include the masks of subregisters supported by any of the class members, not just the ones supported by all class members. This fixes problems when coalescing towards a subclass with additional subregisters available. The attached testcase works fine as is, but does crash if you enable subregister liveness on x86 without this change applied. llvm-svn: 232652
* Revert the non-cleanup part of r230769 because it introduced a ↵Nick Lewycky2015-03-031-2/+0
| | | | | | non-determinism found only in the names of symbols. llvm-svn: 231058
* Silence variable set but not used warning in CodeGenRegisters.cpp, NFC.Yaron Keren2015-02-281-0/+1
| | | | llvm-svn: 230854
* Switch a std::map to a DenseMap in CodeGenRegisters.Owen Anderson2015-02-271-0/+2
| | | | | | | | The keys of the map are unique by pointer address, so there's no need to use the llvm::less comparator. This allows us to use DenseMap instead, which reduces tblgen time by 20% on my stress test. llvm-svn: 230769
* MSVC 2013 does not ICE on this code in the same fashion that MSVC 2012 did; NFC.Aaron Ballman2015-02-161-3/+1
| | | | llvm-svn: 229422
* STLExtras: Provide less/equal functors with templated function call ↵David Blaikie2015-02-021-12/+11
| | | | | | | | | | | | | | | | operators, plus a deref'ing functor template utility Similar to the C++14 void specializations of these templates, useful as a stop-gap until LLVM switches to '14. Example use-cases in tblgen because I saw some functors that looked like they could be simplified/refactored. Reviewers: dexonsmith Differential Revision: http://reviews.llvm.org/D7324 llvm-svn: 227828
* Replace another std::set in the core of CodeGenRegister, this time with ↵Owen Anderson2015-01-311-39/+46
| | | | | | | | sorted arrays. The hot path through this region of code does lots of batch inserts into sets. By storing them as sorted arrays, we can defer the sorting to the end of the batch, which is dramatically more efficient. This reduces tblgen runtime by 25% on my worst-case target. llvm-svn: 227682
* Change more of the guts of CodeGenRegister's RegUnit tracking to be based on ↵Owen Anderson2015-01-311-54/+29
| | | | | | | | bit vectors. This is a continuation of my prior work to move some of the inner workings for CodeGenRegister to use bit vectors when computing about register units. This is highly beneficial to TableGen runtime on targets with large, dense register files. This patch represents a ~40% runtime reduction over and above my earlier improvement on a stress test of this case. llvm-svn: 227678
* Change a very hot piece of code in TableGen's register unit computations to ↵Owen Anderson2015-01-301-1/+14
| | | | | | | | | | | | | | | | use bit vectors rather than arrays. For target descriptions with very large and very dense register files, TableGen can take an extremely long time to run. This change makes a dent in that (~15% in my measurements) by accelerating the single hottest operation with better data structures. I believe there's still a lot of room to make this even faster with more global changes that require replacing some of the existing datastructures in this area with bit vectors, but that's a more involved change and I wanted to get this simpler improvement in first. llvm-svn: 227562
* Clean up static analyzer warnings.Michael Ilseman2014-12-121-0/+1
| | | | | | | | | Clang's static analyzer found several potential cases of undefined behavior, use of un-initialized values, and potentially null pointer dereferences in tablegen, Support, MC, and ADT. This cleans them up with specific assertions on the assumptions of the code. llvm-svn: 224154
* Tablegen'erate lanemasks for register units.Matthias Braun2014-12-101-0/+37
| | | | | | Now we can relate lanemasks in a virtual register to register units. llvm-svn: 223889
* Add function that translates subregister lane masks to other subregs.Matthias Braun2014-12-101-0/+64
| | | | | | | This works like the composeSubRegisterIndices() function but transforms a subregister lane mask instead of a subregister index. llvm-svn: 223874
* Let tablegen compute maximum lanemask for regs/regclasses.Matthias Braun2014-12-101-3/+15
| | | | | | | | Let tablegen compute the combination of subregister lanemasks for all subregisters in a register/register class. This is preparation for further work subregister allocation llvm-svn: 223873
* range-for some thingsDavid Blaikie2014-12-031-19/+12
| | | | llvm-svn: 223263
* Simplify CodeGenRegBank::inferMatchingSuperRegClass & its caller by passing ↵David Blaikie2014-12-031-16/+16
| | | | | | an iterator rather than index llvm-svn: 223262
* Simplify ownership of RegClasses by using list<CodeGenRegisterClass> instead ↵David Blaikie2014-12-031-57/+59
| | | | | | | | | | of vector<CodeGenRegisterClass*> This complicates a few algorithms due to not having random access, but not by a huge degree I don't think (open to debate/design discussion/etc). llvm-svn: 223261
* Range-for some stuff related to RegClasses, and comment cases where ↵David Blaikie2014-12-031-58/+66
| | | | | | range-for isn't suitable. llvm-svn: 223260
OpenPOWER on IntegriCloud