| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
llvm-svn: 371253
|
|
|
|
| |
llvm-svn: 369674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
CodeGenRegisterClass::getValueTypeNum
Avoids costly std::map copies inside ValueTypeByHwMode constructor
llvm-svn: 339884
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By keeping track of unique_ptrs to the synthesized definitions in
CodeGenRegBank we avoid leaking them.
Reviewers: dsanders, kparzysz, stoklund
Reviewed By: dsanders
Differential Revision: https://reviews.llvm.org/D47462
llvm-svn: 333434
|
|
|
|
|
|
|
|
|
| |
This is used by llvm tblgen as well as by LLVM Targets, so the only
common place is Support for now. (maybe we need another target for these
sorts of things - but for now I'm at least making them correct & we can
make them better if/when people have strong feelings)
llvm-svn: 328395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Registers E[A-D]X, E[SD]I, E[BS]P, and EIP have 16-bit subregisters
that cover the low halves of these registers. This change adds artificial
subregisters for the high halves in order to differentiate (in terms of
register units) between the 32- and the low 16-bit registers.
This patch contains parts that aim to preserve the calculated register
pressure. This is in order to preserve the current codegen (minimize the
impact of this patch). The approach of having artificial subregisters
could be used to fix PR23423, but the pressure calculation would need
to be changed.
Differential Revision: https://reviews.llvm.org/D43353
llvm-svn: 328016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
places. NFC
llvm-svn: 304386
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This will allow to switch to a different string storage in an upcoming
commit.
llvm-svn: 288612
|
|
|
|
|
|
| |
This preparation to remove SetVector.h dependency on SmallSet.h.
llvm-svn: 288256
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenSubRegIndex. NFC"
It turns out we iterate over this map a fair amount and the order
matters for clang to be deterministic. See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160919/391315.html
This reverts r279875.
llvm-svn: 282040
|
|
|
|
|
|
|
|
|
| |
This mapping is between pointers, which DenseMap is particularly good
at. Most targets aren't really affected, but if there's a lot of
subregister composition this can shave off a good chunk of time from
generating registers.
llvm-svn: 279875
|
|
|
|
|
|
| |
This will be used in the upcoming "DetectDeadLanes" pass.
llvm-svn: 267850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed some unused headers, replaced some headers with forward class declarations.
Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'
Patch by Eugene Kosov <claprix@yandex.ru>
Differential Revision: http://reviews.llvm.org/D19219
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
|
|
|
|
|
|
|
|
|
|
| |
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
|