| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 231059
|
| |
|
|
|
|
| |
non-determinism found only in the names of symbols.
llvm-svn: 231058
|
| |
|
|
| |
llvm-svn: 230964
|
| |
|
|
| |
llvm-svn: 230909
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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: 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
|
| |
|
|
|
|
|
|
|
|
| |
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)
Changes made by clang-tidy with minor tweaks.
llvm-svn: 215558
|
| |
|
|
| |
llvm-svn: 211100
|
| |
|
|
|
|
| |
instead of comparing to nullptr.
llvm-svn: 206356
|
| |
|
|
|
|
|
|
|
| |
Utilize the previous move of MVT to a separate header for all trivial
cases (that don't need any further restructuring).
Reviewed By: Tim Northover
llvm-svn: 204003
|
| |
|
|
|
|
|
| |
The code added nothing but potentially disabled move semantics and made
types non-trivially copyable.
llvm-svn: 203563
|
| |
|
|
|
|
|
| |
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
llvm-svn: 200018
|
| |
|
|
|
|
| |
This lets heuristics easily pick the most important set to follow.
llvm-svn: 187108
|
| |
|
|
|
|
| |
size.
llvm-svn: 186274
|
| |
|
|
|
|
|
| |
This also makes TableGen able to compute sizes/offsets of synthesized
indices representing tuples.
llvm-svn: 183061
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE: If this broke your out-of-tree backend, in *RegisterInfo.td, change
the instances of SubRegIndex that have a comps template arg to use the
ComposedSubRegIndex class instead.
In TableGen land, this adds Size and Offset attributes to SubRegIndex,
and the ComposedSubRegIndex class, for which the Size and Offset are
computed by TableGen. This also adds an accessor in MCRegisterInfo, and
Size/Offsets for the X86 and ARM subreg indices.
llvm-svn: 183020
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The size reduction in the RegDiffLists are rather dramatic. Here are a few
size differences for MCTargetDesc.o files (before and after) in bytes:
R600 - 36160B - 11184B - 69% reduction
ARM - 28480B - 8368B - 71% reduction
Mips - 816B - 576B - 29% reduction
One side effect of dynamically computing the aliases is that the iterator does
not guarantee that the entries are ordered or that duplicates have been removed.
The documentation implies this is a safe assumption and I found no clients that
requires these attributes (i.e., strict ordering and uniqueness).
My local LNT tester results showed no execution-time failures or significant
compile-time regressions (i.e., beyond what I would consider noise) for -O0g,
-O2 and -O3 runs on x86_64 and i386 configurations.
rdar://12906217
llvm-svn: 182783
|
| |
|
|
|
|
|
|
| |
This lane mask provides information about which register lanes
completely cover super-registers. See the block comment before
getCoveringLanes().
llvm-svn: 182034
|
| |
|
|
|
|
|
| |
Not passing vector references around makes it possible to use
SmallVector in most places.
llvm-svn: 177235
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
At build-time register pressure was always computed in terms of
register units. But the compile-time API was expressed in terms of
register classes because it was intended for virtual registers (and
physical register units weren't yet used anywhere in codegen).
Now that the codegen uses physreg units consistently, prepare for
tracking register pressure also in terms of live units, not live
registers.
llvm-svn: 169360
|
| |
|
|
|
|
|
| |
I've tried to find main moudle headers where possible, but the TableGen
stuff may warrant someone else looking at it.
llvm-svn: 169251
|
| |
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
| |
|
|
| |
llvm-svn: 164767
|
| |
|
|
|
|
| |
list of registers every time we want to look up a register by name.
llvm-svn: 163659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sub-register lane masks are bitmasks that can be used to determine if
two sub-registers of a virtual register will overlap. For example, ARM's
ssub0 and ssub1 sub-register indices don't overlap each other, but both
overlap dsub0 and qsub0.
The lane masks will be accurate on most targets, but on targets that use
sub-register indexes in an irregular way, the masks may conservatively
report that two sub-register indices overlap when the eventually
allocated physregs don't.
Irregular register banks also mean that the bits in a lane mask can't be
mapped onto register units, but the concept is similar.
llvm-svn: 163630
|
| |
|
|
|
|
|
| |
Preserve the Composites map in the CodeGenSubRegIndex class so it can be
used to determine which sub-register indices can actually be composed.
llvm-svn: 163629
|
| |
|
|
|
|
|
|
|
|
|
| |
TableGen sometimes synthesizes missing sub-register indexes. Emit these
indexes as enumerators in the target namespace along with the
user-defined ones.
Also take this opportunity to stop creating new Record objects for
synthetic indexes.
llvm-svn: 161964
|
| |
|
|
| |
llvm-svn: 157684
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Register units are already used internally in TableGen to compute
register pressure sets and overlapping registers. This patch makes them
available to the code generators.
The register unit lists are differentially encoded so they can be reused
for many related registers. This keeps the total size of the lists below
200 bytes for most targets. ARM has the largest table at 560 bytes.
Add an MCRegUnitIterator for traversing the register unit lists. It
provides an abstract interface so the representation can be changed in
the future without changing all clients.
llvm-svn: 157650
|
| |
|
|
|
|
|
| |
CodeGenRegisterClass has two constructors. Both need to compute the
TopoSigs BitVector.
llvm-svn: 157271
|
| |
|
|
|
|
|
|
|
|
|
| |
TableGen already computes register units as the basic unit of
interference. We can use that to compute the set of overlapping
registers.
This means that we can easily compute overlap sets for one register at a
time. There is no benefit to computing all registers at once.
llvm-svn: 156960
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Besides the weight, we also want to store up to two root registers per
unit. Most units will have a single root, the leaf register they
represent. Units created for ad hoc aliasing get two roots: The two
aliasing registers.
The root registers can be used to compute the set of overlapping
registers.
llvm-svn: 156792
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The ad hoc aliasing specified in the 'Aliases' list in .td files is
currently only used by computeOverlaps(). It will soon be needed to
build accurate register units as well, so build the undirected graph in
CodeGenRegister::buildObjectGraph() instead.
Aliasing is a symmetric relationship with only one direction specified
in the .td files. Make sure both directions are represented in
getExplicitAliases().
llvm-svn: 156762
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TableGen creates new register classes and sub-register indices based on
the sub-register structure present in the register bank. So far, it has
been doing that on a per-register basis, but that is not very efficient.
This patch teaches TableGen to compute topological signatures for
registers, and use that to reduce the amount of redundant computation.
Registers get the same TopoSig if they have identical sub-register
structure.
TopoSigs are not currently exposed outside TableGen.
llvm-svn: 156761
|
| |
|
|
|
|
|
|
| |
Don't compute the SuperRegs list until the sub-register graph is
completely finished. This guarantees that the list of super-registers is
properly topologically ordered, and has no duplicates.
llvm-svn: 156629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sub-registers explicitly listed in SubRegs in the .td files form a
tree. In a complicated register bank, it is possible to have
sub-register relationships across sub-trees. For example, the ARM NEON
double vector Q0_Q1 is a tree:
Q0_Q1 = [Q0, Q1], Q0 = [D0, D1], Q1 = [D2, D3]
But we also define the DPair register D1_D2 = [D1, D2] which is fully
contained in Q0_Q1.
This patch teaches TableGen to find such sub-register relationships, and
assign sub-register indices to them. In the example, TableGen will
create a dsub_1_dsub_2 sub-register index, and add D1_D2 as a
sub-register of Q0_Q1.
This will eventually enable the coalescer to handle copies of skewed
sub-registers.
llvm-svn: 156587
|