| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This adds a boolean member variable to the PassManagerBuilder to control loop
rerolling (just like we have for unrolling and the various vectorization
options). This is necessary for control by the frontend. Loop rerolling remains
disabled by default at all optimization levels.
llvm-svn: 194966
|
| |
|
|
|
|
|
|
| |
This reverts commit f1d9fe9d04ce93f6d5dcebbd2cb6a07414d7a029.
This was causing PR17964. We need to use thread data before regular data.
llvm-svn: 194960
|
| |
|
|
|
|
| |
illegal constants.
llvm-svn: 194959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
division and make the private scale in BlockFrequency more performant.
This change is the first in a series of changes improving LLVM's Block
Frequency propogation implementation to not lose probability mass in
branchy code when propogating block frequency information from a basic
block to its successors. This patch is a simple infrastructure
improvement that does not actually modify the block frequency
algorithm. The specific changes are:
1. Changes the division algorithm used when scaling block frequencies by
branch probabilities to a short division algorithm. This gives us the
remainder for free as well as provides a nice speed boost. When I
benched the old routine and the new routine on a Sandy Bridge iMac with
disabled turbo mode performing 8192 iterations on an array of length
32768, I saw ~600% increase in speed in mean/median performance.
2. Exposes a scale method that returns a remainder. This is important so
we can ensure that when we scale a block frequency by some branch
probability BP = N/D, the remainder from the division by D can be
retrieved and propagated to other children to ensure no probability mass
is lost (more to come on this).
llvm-svn: 194950
|
| |
|
|
| |
llvm-svn: 194945
|
| |
|
|
| |
llvm-svn: 194944
|
| |
|
|
|
|
|
|
|
|
|
| |
Generally speaking, control flow paths with error reporting calls are cold.
So far, error reporting calls are calls to perror and calls to fprintf,
fwrite, etc. with stderr as the stream. This can be extended in the future.
The primary motivation is to improve block placement (the cold attribute
affects the static branch prediction heuristics).
llvm-svn: 194943
|
| |
|
|
|
|
|
|
| |
Implementing this on bigendian platforms could get strange. I added a
target hook, getStackSlotRange, per Jakob's recommendation to make
this as explicit as possible.
llvm-svn: 194942
|
| |
|
|
| |
llvm-svn: 194941
|
| |
|
|
| |
llvm-svn: 194940
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a loop rerolling pass: the opposite of (partial) loop unrolling. The
transformation aims to take loops like this:
for (int i = 0; i < 3200; i += 5) {
a[i] += alpha * b[i];
a[i + 1] += alpha * b[i + 1];
a[i + 2] += alpha * b[i + 2];
a[i + 3] += alpha * b[i + 3];
a[i + 4] += alpha * b[i + 4];
}
and turn them into this:
for (int i = 0; i < 3200; ++i) {
a[i] += alpha * b[i];
}
and loops like this:
for (int i = 0; i < 500; ++i) {
x[3*i] = foo(0);
x[3*i+1] = foo(0);
x[3*i+2] = foo(0);
}
and turn them into this:
for (int i = 0; i < 1500; ++i) {
x[i] = foo(0);
}
There are two motivations for this transformation:
1. Code-size reduction (especially relevant, obviously, when compiling for
code size).
2. Providing greater choice to the loop vectorizer (and generic unroller) to
choose the unrolling factor (and a better ability to vectorize). The loop
vectorizer can take vector lengths and register pressure into account when
choosing an unrolling factor, for example, and a pre-unrolled loop limits that
choice. This is especially problematic if the manual unrolling was optimized
for a machine different from the current target.
The current implementation is limited to single basic-block loops only. The
rerolling recognition should work regardless of how the loop iterations are
intermixed within the loop body (subject to dependency and side-effect
constraints), but the significant restriction is that the order of the
instructions in each iteration must be identical. This seems sufficient to
capture all current use cases.
This pass is not currently enabled by default at any optimization level.
llvm-svn: 194939
|
| |
|
|
| |
llvm-svn: 194936
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InstCombine, in visitFPTrunc, applies the following optimization to sqrt calls:
(fptrunc (sqrt (fpext x))) -> (sqrtf x)
but does not apply the same optimization to llvm.sqrt. This is a problem
because, to enable vectorization, Clang generates llvm.sqrt instead of sqrt in
fast-math mode, and because this optimization is being applied to sqrt and not
applied to llvm.sqrt, sometimes the fast-math code is slower.
This change makes InstCombine apply this optimization to llvm.sqrt as well.
This fixes the specific problem in PR17758, although the same underlying issue
(optimizations applied to libcalls are not applied to intrinsics) exists for
other optimizations in SimplifyLibCalls.
llvm-svn: 194935
|
| |
|
|
| |
llvm-svn: 194934
|
| |
|
|
| |
llvm-svn: 194932
|
| |
|
|
|
|
|
|
| |
warn_unused_result.
Fix ScalarEvolution bugs uncovered by this.
llvm-svn: 194928
|
| |
|
|
| |
llvm-svn: 194927
|
| |
|
|
|
|
| |
Per Rafael's review of r194514.
llvm-svn: 194926
|
| |
|
|
|
|
| |
This is common in bitfield code.
llvm-svn: 194925
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 194917
|
| |
|
|
| |
llvm-svn: 194906
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The tests just hit this with a different sized
address space since I haven't figured out how
to use this to break it.
I thought I committed this a long time ago,
and I'm not sure why missing this hasn't caused
any problems.
llvm-svn: 194903
|
| |
|
|
|
|
| |
CompileUnit::createAndAddDIE.
llvm-svn: 194902
|
| |
|
|
| |
llvm-svn: 194901
|
| |
|
|
|
|
|
|
|
| |
and update test cases accordingly.
This doesn't affect the output dumped using llvm-dwarfdump, but
readelf does now dump the debug_loc section.
llvm-svn: 194898
|
| |
|
|
|
|
| |
DICompileUnit instead of a raw MDNode*.
llvm-svn: 194895
|
| |
|
|
|
|
| |
MDNode* for the CU metadata node
llvm-svn: 194893
|
| |
|
|
| |
llvm-svn: 194892
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented aarch64 Neon scalar vfma_lane intrinsics
Implemented aarch64 Neon scalar vfms_lane intrinsics
Implemented legacy vmul_n_f64, vmul_lane_f64, vmul_laneq_f64
intrinsics (v1f64 parameter type) using Neon scalar instructions.
Implemented legacy vfma_lane_f64, vfms_lane_f64,
vfma_laneq_f64, vfms_laneq_f64 intrinsics (v1f64 parameter type)
using Neon scalar instructions.
llvm-svn: 194888
|
| |
|
|
| |
llvm-svn: 194883
|
| |
|
|
| |
llvm-svn: 194882
|
| |
|
|
|
|
|
|
| |
until we know that folding will be successful.
No functional change.
llvm-svn: 194880
|
| |
|
|
| |
llvm-svn: 194879
|
| |
|
|
|
|
|
|
|
|
|
| |
When we vectorize a scalar access with no alignment specified, we have to set
the target's abi alignment of the scalar access on the vectorized access.
Using the same alignment of zero would be wrong because most targets will have a
bigger abi alignment for vector types.
This probably fixes PR17878.
llvm-svn: 194876
|
| |
|
|
| |
llvm-svn: 194875
|
| |
|
|
|
|
|
| |
This is the first of a few similar patches. We'll see how far it
goes/makes sense.
llvm-svn: 194871
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
| |
|
|
|
|
|
|
|
|
|
| |
The error reported the number of explicit operands,
but that isn't what is checked. In my case, this
resulted in the confusing errors
"Too few operands." followed shortly by
"8 operands expected, but 8 given."
llvm-svn: 194862
|
| |
|
|
|
|
| |
Patch by Keno Fischer!
llvm-svn: 194859
|
| |
|
|
| |
llvm-svn: 194858
|
| |
|
|
|
|
| |
AaronBallman. Thanks for the excellent review.
llvm-svn: 194857
|
| |
|
|
|
|
| |
pulling them under 80-columns. No functionality changed.
llvm-svn: 194856
|
| |
|
|
|
|
| |
rather than the vector equivalent.
llvm-svn: 194853
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Make identify_magic to recognize COFF import file.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2165
llvm-svn: 194852
|
| |
|
|
| |
llvm-svn: 194848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to use std::map<IndicesVector, LoadInst*> for OriginalLoads, and when we
try to promote two arguments, they will both write to OriginalLoads causing
created loads for the two arguments to have the same original load. And the same
tbaa tag and alignment will be put to the created loads for the two arguments.
The fix is to use std::map<std::pair<Argument*, IndicesVector>, LoadInst*>
for OriginalLoads, so each Argument will write to different parts of the map.
PR17906
llvm-svn: 194846
|
| |
|
|
|
|
|
|
| |
0xffff does not mean that there are 65535 sections in a COFF file but
indicates that it's a COFF import library. This patch fixes SEGV error
when an import library file is passed to llvm-readobj.
llvm-svn: 194844
|
| |
|
|
|
|
| |
If getDIE() fails, getOrCreateContextDIE() should also return the CUDie.
llvm-svn: 194843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop folding constant adds into GEP when the type size doesn't match.
Otherwise, the adds' operands are effectively being promoted, changing the
conditions of an overflow. Results are different when:
sext(a) + sext(b) != sext(a + b)
Problem originally found on x86-64, but also fixed issues with ARM and PPC,
which used similar code.
<rdar://problem/15292280>
Patch by Duncan Exon Smith!
llvm-svn: 194840
|
| |
|
|
|
|
| |
This fixes a crash with GNOME settings manager.
llvm-svn: 194836
|