| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
array
Summary:
For Sparc the namespace (SP) is different from the target name (Sparc),
which causes the name of the array in this declaration to differ from
the name used in the definition.
Patch by Daniel Cederman.
Reviewers: jyknight
Subscribers: llvm-commits, jyknight
Differential Revision: https://reviews.llvm.org/D23650
llvm-svn: 287528
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D25614
Reviewers: qcolombet
Subscribers: qcolombet, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D25617
llvm-svn: 287438
|
| |
|
|
|
|
|
| |
clang-tidy's performance-unnecessary-copy-initialization with some manual
fixes. No functional changes intended.
llvm-svn: 270988
|
| |
|
|
|
|
|
|
|
|
|
|
| |
minor fixes; other minor fixes.
Make generated code more readable.
Fix some Include What You Use warnings.
Differential revision: http://reviews.llvm.org/D20317
llvm-svn: 269783
|
| |
|
|
|
|
| |
This will be used in the upcoming "DetectDeadLanes" pass.
llvm-svn: 267850
|
| |
|
|
|
|
|
|
|
| |
This function performs the reverse computation of
composeSubRegIndexLaneMask().
It will be used in the upcoming "DetectDeadLanes" pass.
llvm-svn: 267849
|
| |
|
|
|
|
| |
It should never have been accessed.
llvm-svn: 248246
|
| |
|
|
|
|
| |
better place.
llvm-svn: 248245
|
| |
|
|
|
|
|
|
|
|
| |
file. Additionally const correct a couple static array.
Previously the code added an extra nullptr entry to a static array and then created an ArrayRef with a size one less than the static array. If there were no other entries the array would just contain the nullptr and the ArrayRef would be crated with size 0.
Instead, put the right number of entries in the array and explicitly emit 'None' if the size would be 0. This allows the static array constructor of makeArrayRef to be used.
llvm-svn: 248244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch does the following:
* Fix FIXME on `needsStackRealignment`: it is now shared between multiple targets, implemented in `TargetRegisterInfo`, and isn't `virtual` anymore. This will break out-of-tree targets, silently if they used `virtual` and with a build error if they used `override`.
* Factor out `canRealignStack` as a `virtual` function on `TargetRegisterInfo`, by default only looks for the `no-realign-stack` function attribute.
Multiple targets duplicated the same `needsStackRealignment` code:
- Aarch64.
- ARM.
- Mips almost: had extra `DEBUG` diagnostic, which the default implementation now has.
- PowerPC.
- WebAssembly.
- x86 almost: has an extra `-force-align-stack` option, which the default implementation now has.
The default implementation of `needsStackRealignment` used to just return `false`. My current patch changes the behavior by simply using the above shared behavior. This affects:
- AMDGPU
- BPF
- CppBackend
- MSP430
- NVPTX
- Sparc
- SystemZ
- XCore
- Out-of-tree targets
This is a breaking change! `make check` passes.
The only implementation of the `virtual` function (besides the slight different in x86) was Hexagon (which did `MF.getFrameInfo()->getMaxAlignment() > 8`), and potentially some out-of-tree targets. Hexagon now uses the default implementation.
`needsStackRealignment` was being overwritten in `<Target>GenRegisterInfo.inc`, to return `false` as the default also did. That was odd and is now gone.
Reviewers: sunfish
Subscribers: aemerson, llvm-commits, jfb
Differential Revision: http://reviews.llvm.org/D11160
llvm-svn: 242727
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The target frame lowering's concrete type is always known in RegisterInfo, yet it's only sometimes devirtualized through a static_cast. This change adds an auto-generated static function <Target>GenRegisterInfo::getFrameLowering(const MachineFunction &MF) which does this devirtualization, and uses this function in all targets which can.
This change was suggested by sunfish in D11070 for WebAssembly, I figure that I may as well improve the other targets while I'm here.
Subscribers: sunfish, ted, llvm-commits, jfb
Differential Revision: http://reviews.llvm.org/D11093
llvm-svn: 241921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements serialization of the register mask machine
operands. This commit serializes only the call preserved register
masks that are defined by a target, it doesn't serialize arbitrary
register masks.
This commit also extends the TargetRegisterInfo class and TableGen so that
the users of TRI can get the list of all the call preserved register masks and
their names.
Reviewers: Duncan P. N. Exon Smith
Differential Revision: http://reviews.llvm.org/D10673
llvm-svn: 240966
|
| |
|
|
| |
llvm-svn: 233857
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
we can inspect the subtarget and function when computing values.
llvm-svn: 231951
|
| |
|
|
| |
llvm-svn: 230964
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Primarily done by using SequenceToOffsetTable to reduce the register pressure set tables and then sizing the indices into the tables appropriately. Size a few other table entries based on content as well. Reduces X86RegisterInfo.o by ~9k.
llvm-svn: 222621
|
| |
|
|
|
|
| |
RegisterInfo output file.
llvm-svn: 222508
|
| |
|
|
| |
llvm-svn: 222411
|
| |
|
|
|
|
| |
output.
llvm-svn: 222410
|
| |
|
|
|
|
|
|
| |
reduce static table size and number of relocation entries.
Indices into the table are stored in each MCRegisterClass instead of a pointer. A new method, getRegClassName, is added to MCRegisterInfo and TargetRegisterInfo to lookup the string in the table.
llvm-svn: 222118
|
| |
|
|
| |
llvm-svn: 207611
|
| |
|
|
| |
llvm-svn: 205610
|
| |
|
|
|
|
| |
class.
llvm-svn: 203378
|
| |
|
|
| |
llvm-svn: 202344
|
| |
|
|
| |
llvm-svn: 190770
|
| |
|
|
|
|
| |
Otherwise SequenceToOffsetTable will sort by pointer and becomes non-deterministic.
llvm-svn: 190514
|
| |
|
|
|
|
|
|
|
|
| |
This field specifies registers that are preserved across function calls,
but that should not be included in the generates SaveList array.
This can be used ot generate regmasks for architectures that save
registers through other means, like SPARC's register windows.
llvm-svn: 189084
|
| |
|
|
|
|
| |
functional changes intended.
llvm-svn: 187159
|
| |
|
|
|
|
| |
This lets heuristics easily pick the most important set to follow.
llvm-svn: 187108
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
algorithm when assigning EnumValues to the synthesized registers.
The current algorithm, LessRecord, uses the StringRef compare_numeric
function. This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:
T1
T1_W
T1_X
T1_XYZW
T1_Y
T1_Z
T2
T2_W
T2_X
T2_XYZW
T2_Y
T2_Z
In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another. However, in other parts
of the register bank, the scaling factors are different:
dEnum/dN = 5:
KC0_128_W
KC0_128_X
KC0_128_XYZW
KC0_128_Y
KC0_128_Z
KC0_129_W
KC0_129_X
KC0_129_XYZW
KC0_129_Y
KC0_129_Z
The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'. This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1. For example, the registers are now sorted as
follows:
T1
T2
T3
...
T0_W
T1_W
T2_W
...
T0_X
T1_X
T2_X
...
KC0_128_W
KC0_129_W
KC0_130_W
...
For the Mips and R600 I see a 19% and 6% reduction in size, respectively. I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes). I suspect there will be even
greater wins for targets with larger register files.
Patch reviewed by Jakob.
rdar://14006013
llvm-svn: 185094
|
| |
|
|
| |
llvm-svn: 183426
|
| |
|
|
|
|
|
| |
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
|