| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14597
llvm-svn: 253095
|
|
|
|
|
|
|
| |
This makes it slightly easier to handle classes with and without
subregister uniformly.
llvm-svn: 252671
|
|
|
|
| |
llvm-svn: 238806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
thing and is already used in most places. NFC.
llvm-svn: 237341
|
|
|
|
| |
llvm-svn: 235697
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 234963
|
|
|
|
| |
llvm-svn: 233752
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
non-determinism found only in the names of symbols.
llvm-svn: 231058
|
|
|
|
| |
llvm-svn: 230854
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 229422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Now we can relate lanemasks in a virtual register to register units.
llvm-svn: 223889
|
|
|
|
|
|
|
| |
This works like the composeSubRegisterIndices() function but transforms
a subregister lane mask instead of a subregister index.
llvm-svn: 223874
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 223263
|
|
|
|
|
|
| |
an iterator rather than index
llvm-svn: 223262
|
|
|
|
|
|
|
|
|
|
| |
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 isn't suitable.
llvm-svn: 223260
|
|
|
|
| |
llvm-svn: 222959
|
|
|
|
| |
llvm-svn: 222958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
semantics (at least when removal is not needed) without the extra indirection/ownership complexity
Order matters for this container, it seems (using a forward_list and
replacing the original push_backs with emplace_fronts caused test
failures). I didn't look too deeply into why.
(& in retrospect, I might go back & change some of the forward_lists I
introduced to deques anyway - since most don't require removal, deque is
a more memory-friendly data structure (moderate locality while not
invalidating pointers))
llvm-svn: 222950
|
|
|
|
|
|
| |
value in their container, removing the indirection
llvm-svn: 222949
|
|
|
|
| |
llvm-svn: 222930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
|
|
|
|
|
|
| |
'const' from some other ArrayRef uses since its implicitly const already.
llvm-svn: 216524
|
|
|
|
| |
llvm-svn: 216351
|
|
|
|
|
|
| |
definition below all of the header #include lines, TableGen edition.
llvm-svn: 206846
|
|
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206254
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 205110
|
|
|
|
| |
llvm-svn: 202937
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 202751
|
|
|
|
|
|
| |
Remove the old functions.
llvm-svn: 202636
|
|
|
|
|
|
|
|
| |
of boilerplate.
No intended functionality change.
llvm-svn: 202588
|
|
|
|
|
|
| |
facilitate. Remove TGValueTypes.cpp since its unused now (and may have been before).
llvm-svn: 200036
|
|
|
|
|
|
|
|
| |
This makes using array_pod_sort significantly safer. The implementation relies
on function pointer casting but that should be safe as we're dealing with void*
here.
llvm-svn: 191175
|
|
|
|
| |
llvm-svn: 187531
|
|
|
|
|
|
| |
The heuristic that merges register pressure sets was bogus for ARM's S/D regs.
llvm-svn: 187479
|
|
|
|
| |
llvm-svn: 187478
|
|
|
|
|
|
| |
This lets heuristics easily pick the most important set to follow.
llvm-svn: 187108
|
|
|
|
|
|
| |
size.
llvm-svn: 186274
|