| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Instead just use APInt objects and only create a ConstantInt at the end if we need it for the Offset.
llvm-svn: 307270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ScaledReg and Scale.
When the formulae search space is huge, LSR uses a series of heuristic to keep
pruning the search space until the number of possible solutions are within
certain limit.
The big hammer of the series of heuristics is NarrowSearchSpaceByPickingWinnerRegs,
which picks the register which is used by the most LSRUses and deletes the other
formulae which don't use the register. This is a effective way to prune the search
space, but quite often not a good way to keep the best solution. We saw cases before
that the heuristic pruned the best formula candidate out of search space.
To relieve the problem, we introduce a new heuristic called
NarrowSearchSpaceByFilterFormulaWithSameScaledReg. The basic idea is in order to
reduce the search space while keeping the best formula, we want to keep as many
formulae with different Scale and ScaledReg as possible. That is because the central
idea of LSR is to choose a group of loop induction variables and use those induction
variables to represent LSRUses. An induction variable candidate is often represented
by the Scale and ScaledReg in a formula. If we have more formulae with different
ScaledReg and Scale to choose, we have better opportunity to find the best solution.
That is why we believe pruning search space by only keeping the best formula with the
same Scale and ScaledReg should be more effective than PickingWinnerReg. And we use
two criteria to choose the best formula with the same Scale and ScaledReg. The first
criteria is to select the formula using less non shared registers, and the second
criteria is to select the formula with less cost got from RateFormula. The patch
implements the heuristic before NarrowSearchSpaceByPickingWinnerRegs, which is the
last resort.
Testing shows we get 1.8% and 2% on two internal benchmarks on x86. llvm nightly
testsuite performance is neutral. We also tried lsr-exp-narrow and it didn't help
on the two improved internal cases we saw.
Differential Revision: https://reviews.llvm.org/D34583
llvm-svn: 307269
|
| |
|
|
| |
llvm-svn: 307268
|
| |
|
|
| |
llvm-svn: 307263
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Added MachineVerifier code to check register ties more thoroughly, especially so that physical registers that are tied are the same. This may help e.g. when creating MIR files.
Original patch by Jesper Antonsson
Reviewers: stoklund, sanjoy, qcolombet
Reviewed By: qcolombet
Subscribers: qcolombet, llvm-commits
Differential Revision: https://reviews.llvm.org/D34394
llvm-svn: 307259
|
| |
|
|
|
|
| |
mask types
llvm-svn: 307257
|
| |
|
|
| |
llvm-svn: 307255
|
| |
|
|
| |
llvm-svn: 307254
|
| |
|
|
|
|
| |
First step toward supporting shuffle combining to EXTRQ/INSERTQ.
llvm-svn: 307250
|
| |
|
|
|
|
|
|
|
| |
non-negative values and indvars"""
It appears that the problem is still there. Needs more analysis to understand why
SaturatedMultiply test fails.
llvm-svn: 307249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
During remat, some subranges might end up having invalid segments which caused problems for later
coalescing.
Added in a check to remove segments that are invalidated as part of the remat.
See http://llvm.org/PR33524
Subscribers: MatzeB, qcolombet
Differential Revision: https://reviews.llvm.org/D34391
llvm-svn: 307247
|
| |
|
|
|
|
| |
Map hard G_FCMP operands to FPR and the result to GPR.
llvm-svn: 307245
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
values and indvars""
It seems that the patch was reverted by mistake. Clang testing showed failure of the
MathExtras.SaturatingMultiply test, however I was unable to reproduce the issue on the
fresh code base and was able to confirm that the transformation introduced by the change
does not happen in the said test. This gives a strong confidence that the actual reason of
the failure of the initial patch was somewhere else, and that problem now seems to be
fixed. Re-submitting the change to confirm that.
llvm-svn: 307244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This covers both hard and soft float.
Hard float is easy, since it's just Legal.
Soft float is more involved, because there are several different ways to
handle it based on the predicate: one and ueq need not only one, but two
libcalls to get a result. Furthermore, we have large differences between
the values returned by the AEABI and GNU functions.
AEABI functions return a nice 1 or 0 representing true and respectively
false. GNU functions generally return a value that needs to be compared
against 0 (e.g. for ogt, the value returned by the libcall is > 0 for
true). We could introduce redundant comparisons for AEABI as well, but
they don't seem easy to remove afterwards, so we do different processing
based on whether or not the result really needs to be compared against
something (and just truncate if it doesn't).
llvm-svn: 307243
|
| |
|
|
|
|
| |
Get the legalizer to widen small constants.
llvm-svn: 307239
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GlobalExtensions is dereferenced twice, once for iteration and then a check if it is empty.
As a ManagedStatic this dereference forces it's construction which is unnecessary.
Reviewers: efriedma, davide, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: chapuni, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D33381
llvm-svn: 307229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
library."""
This reverts commit ae21ee0b6cacbc1efaf4d42502e71da2f0eb45c3.
The initial revert was done in order to prevent ongoing errors on
chromium bots such as CrWinClangLLD. However, this was done haphazardly
and I didn't realize there were test and compilation failures, so this
revert was reverted. Now that those have been fixed, we can revert the
revert of the revert.
llvm-svn: 307227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
our own .res file."""
This reverts commit 5fecbbbe5049665d86834cf69d8f75db4f392308.
The initial revert was done in order to prevent ongoing errors on
chromium bots such as CrWinClangLLD. However, this was done haphazardly
and I didn't realize there were test and compilation failures, so this
revert was reverted. Now that those have been fixed, we can revert the
revert of the revert.
llvm-svn: 307226
|
| |
|
|
| |
llvm-svn: 307224
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM's definition of dominance allows instructions that are cyclic
in unreachable blocks, e.g.:
%pat = select i1 %condition, @global, i16* %pat
because any instruction dominates an instruction in a block that's
not reachable from entry.
So, remove unreachable blocks from the function, because a) there's
no point in analyzing them and b) GlobalOpt should otherwise grow
some more complicated logic to break these cycles.
Differential Revision: https://reviews.llvm.org/D35028
llvm-svn: 307215
|
| |
|
|
|
|
|
|
|
|
|
|
| |
legalization.
If we are lowering a libcall after legalization, we'll split the return type into a pair of legal values.
Patch by Jatin Bhateja and Eli Friedman.
Differential Revision: https://reviews.llvm.org/D34240
llvm-svn: 307207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dependence analysis was returning incorrect information when using the GEPs
to compute dependences. The analysis uses the GEP indices under certain
conditions, but was doing it incorrectly when the base objects of the GEP are
aliases, but pointing to different locations in the same array.
This patch adds another check for the base objects. If the base pointer SCEVs
are not equal, then the dependence analysis should fall back on the path
that uses the whole SCEV for the dependence check. This fixes PR33567.
Differential Revision: https://reviews.llvm.org/D34702
llvm-svn: 307203
|
| |
|
|
|
|
|
|
| |
ICmpInst::Predicate. NFC
There isn't really an ICmpInst version so we're just accessing the CmpInst version through inheritance.
llvm-svn: 307199
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34966
llvm-svn: 307198
|
| |
|
|
|
|
|
|
|
|
| |
Previously we were generating a void(void) function type
for a weak alias. Update the weak-alias test case to
catch this.
Differential Revision: https://reviews.llvm.org/D34734
llvm-svn: 307194
|
| |
|
|
|
|
|
|
| |
.res file.""
This reverts commit 8c8dce3b8f15d6ebaefc35ce88f15a85c8cdbd6e.
llvm-svn: 307191
|
| |
|
|
|
|
|
|
| |
This reverts commit 165e578e47f1cd38191120aad23a9020fb5476dd.
Forgot to run tests on this.
llvm-svn: 307190
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 600d52c278e123dd08bee24c1f00932b55add8de.
This patch still seems to break CrWinClangLLD, reverting until I can
find root problem.
llvm-svn: 307189
|
| |
|
|
|
|
|
|
|
| |
This patch still seems to break CrWinClangLLD, reverting this once more
until I can discover root problem.
This reverts commit 3dbbc8ce43be50ffde2b1c655c6d3a25796fe78b.
llvm-svn: 307188
|
| |
|
|
|
|
| |
NFC
llvm-svn: 307186
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On power 8 we sometimes insert swaps to deal with the difference between
Little-Endian and Big-Endian. The swap removal pass is supposed to clean up
these swaps. On power 9 we don't need this pass since we do not need to insert
the swaps in the first place.
Commiting on behalf of Stefan Pintilie.
Differential Revision: https://reviews.llvm.org/D34627
llvm-svn: 307185
|
| |
|
|
| |
llvm-svn: 307184
|
| |
|
|
|
|
|
| |
Commiting on behalf of Stefan Pintilie.
Differential Revision: https://reviews.llvm.org/D34829
llvm-svn: 307180
|
| |
|
|
|
|
|
|
|
|
| |
into one with combined shift operand.
For two ROTR operations with shifts C1, C2; combined shift operand will be (C1 + C2) % bitsize.
Differential revision: https://reviews.llvm.org/D12833
llvm-svn: 307179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the exploitation for new power 9 instructions which extract
variable elements from vectors:
VEXTUBLX
VEXTUBRX
VEXTUHLX
VEXTUHRX
VEXTUWLX
VEXTUWRX
Differential Revision: https://reviews.llvm.org/D34032
Commit on behalf of Zaara Syeda (syzaara@ca.ibm.com)
llvm-svn: 307174
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds on to the exploitation added by https://reviews.llvm.org/D33510.
This now catches build vector nodes where the inputs are coming from sign
extended vector extract elements where the indices used by the vector extract
are not correct. We can still use the new hardware instructions by adding a
shuffle to move the elements to the correct indices. I introduced a new PPCISD
node here because adding a vector_shuffle and changing the elements of the
vector_extracts was getting undone by another DAG combine.
Commit on behalf of Zaara Syeda (syzaara@ca.ibm.com)
Differential Revision: https://reviews.llvm.org/D34009
llvm-svn: 307169
|
| |
|
|
|
|
|
|
| |
Make it usable by any class derived (even indirectly) from
LoadedObjectInfo by allowing a custom base class to be specified and
perfect forwarding to the ctor.
llvm-svn: 307166
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
matcher and emitter state machines.
Summary:
Also, made a few minor tweaks to shave off a little more cumulative memory consumption:
* All rules share a single NewMIs instead of constructing their own. Only one
will end up using it.
* Use MIs.resize(1) instead of MIs.clear();MIs.push_back(I) and prevent
GIM_RecordInsn from changing MIs[0].
Depends on D33764
Reviewers: rovka, vitalybuka, ab, t.p.northover, qcolombet, aditya_nandakumar
Reviewed By: ab
Subscribers: kristof.beyls, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D33766
llvm-svn: 307159
|
| |
|
|
| |
llvm-svn: 307158
|
| |
|
|
|
|
|
|
|
|
| |
This adds exact flags to AShr/LShr flags where we can statically
prove it is valid using the range of induction variables. This
allows further optimisations to remove extra loads.
Differential Revision: https://reviews.llvm.org/D34207
llvm-svn: 307157
|
| |
|
|
|
|
|
|
|
|
|
| |
Several integer multiply/divide instructions require use of a
register pair as input and output. This patch moves setting
up the input register pair from C++ code to TableGen, simplifying
the whole process and making it more easily extensible.
No functional change.
llvm-svn: 307155
|
| |
|
|
|
|
|
|
|
|
| |
Fixes a couple of whitespace errors, re-sorts the vector floating-point
instructions to make them more easily extensible, and adds a missing
pseudo instruction.
No functional change.
llvm-svn: 307154
|
| |
|
|
|
|
|
|
|
|
| |
We used to have a helper that replaced an instruction with a libcall.
That turns out to be too aggressive, since sometimes we need to replace
the instruction with at least two libcalls. Therefore, change our
existing helper to only create the libcall and leave the instruction
removal as a separate step. Also rename the helper accordingly.
llvm-svn: 307149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements suggesting other mnemonics when an invalid one is specified,
for example:
$ echo "adXd r1,r2,#3" | llvm-mc -triple arm
<stdin>:1:1: error: invalid instruction, did you mean: add, qadd?
adXd r1,r2,#3
^
The implementation is target agnostic, but as a first step I have added it only
to the ARM backend; so the ARM backend is a good example if someone wants to
enable this too for another target.
Differential Revision: https://reviews.llvm.org/D33128
llvm-svn: 307148
|
| |
|
|
|
|
| |
Extract functionality for determining if the target uses AEABI.
llvm-svn: 307145
|
| |
|
|
| |
llvm-svn: 307144
|
| |
|
|
| |
llvm-svn: 307142
|
| |
|
|
|
|
| |
This isn't used anywhere yet, but I need it for a future commit.
llvm-svn: 307141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Otherwise the fallback path fails with an assertion on x86_64 targets,
when "x86_fp80" is encountered.
Reviewers: t.p.northover, zvi, guyblank
Reviewed By: zvi
Subscribers: rovka, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D34975
llvm-svn: 307140
|
| |
|
|
|
|
|
| |
Add a helper for building simple binary ops like add, mul, sub, and.
This can be used in the future for quickly adding support for or, xor.
llvm-svn: 307139
|