| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
If the load is conditional we can't hoist its 0-iteration instance to
the preheader because that would make it unconditional. Thus we would
access a memory location that the original loop did not access.
llvm-svn: 273991
|
| |
|
|
| |
llvm-svn: 273974
|
| |
|
|
|
|
| |
Only minor manual fixes. No functionality change intended.
llvm-svn: 273808
|
| |
|
|
| |
llvm-svn: 273805
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a straightforward extension of what LoopUnswitch does to
branches to guards. That is, we unswitch
```
for (;;) {
...
guard(loop_invariant_cond);
...
}
```
into
```
if (loop_invariant_cond) {
for (;;) {
...
// There is no need to emit guard(true)
...
}
} else {
for (;;) {
...
guard(false);
// SimplifyCFG will clean this up by adding an
// unreachable after the guard(false)
...
}
}
```
Reviewers: majnemer
Subscribers: mcrosier, llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D21725
llvm-svn: 273801
|
| |
|
|
| |
llvm-svn: 273800
|
| |
|
|
| |
llvm-svn: 273799
|
| |
|
|
| |
llvm-svn: 273798
|
| |
|
|
| |
llvm-svn: 273797
|
| |
|
|
| |
llvm-svn: 273796
|
| |
|
|
| |
llvm-svn: 273795
|
| |
|
|
| |
llvm-svn: 273794
|
| |
|
|
| |
llvm-svn: 273793
|
| |
|
|
|
|
| |
All of its implementation is in just one function.
llvm-svn: 273792
|
| |
|
|
|
|
|
| |
Name-casing and minor style changes to bring the function up to the LLVM
coding style.
llvm-svn: 273791
|
| |
|
|
|
|
| |
This reverts commit r273778, it seems to break UBSan :/
llvm-svn: 273779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SimplifyCFG had logic to insert calls to llvm.trap for two very
particular IR patterns: stores and invokes of undef/null.
While InstCombine canonicalizes certain undefined behavior IR patterns
to stores of undef, phase ordering means that this cannot be relied upon
in general.
There are much better tools than llvm.trap: UBSan and ASan.
N.B. I could be argued into reverting this change if a clear argument as
to why it is important that we synthesize llvm.trap for stores, I'd be
hard pressed to see why it'd be useful for invokes...
llvm-svn: 273778
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: (No semantic change intended).
Reviewers: majnemer, bogner, mzolotukhin
Subscribers: mcrosier, llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D21707
llvm-svn: 273763
|
| |
|
|
|
|
|
|
|
|
| |
r273711 was reverted by r273743. The inliner needs to know about any
call sites in the inlined function. These were obscured if we replaced
a call to undef with an undef but kept the call around.
This fixes PR28298.
llvm-svn: 273753
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21704
llvm-svn: 273747
|
| |
|
|
| |
llvm-svn: 273743
|
| |
|
|
|
|
| |
NFC (whitespace only change)
llvm-svn: 273732
|
| |
|
|
|
|
|
| |
We cannot remove an instruction with no uses just because
SimplifyInstruction succeeds. It may have side effects.
llvm-svn: 273711
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We can avoid repeating the check `isGuaranteedToExecute` when it's already called once while checking if the alignment can be widened for the load/store being hoisted.
The function is invariant for the same instruction `UI` in `isGuaranteedToExecute(*UI, DT, CurLoop, SafetyInfo);`
Reviewers: hfinkel, eli.friedman
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21672
llvm-svn: 273671
|
| |
|
|
|
|
|
| |
This makes the code a little more concise, no functional change is
intended.
llvm-svn: 273644
|
| |
|
|
| |
llvm-svn: 273586
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DeadStoreElimination can currently remove a small store rendered unnecessary by
a later larger one, but could not remove a larger store rendered unnecessary by
a series of later smaller ones. This adds that capability.
It works by keeping a map, which is used as an effective interval map, for each
store later overwritten only partially, and filling in that interval map as
more such stores are discovered. No additional walking or aliasing queries are
used. In the map forms an interval covering the the entire earlier store, then
it is dead and can be removed. The map is used as an interval map by storing a
mapping between the ending offset and the beginning offset of each interval.
I discovered this problem when investigating a performance issue with code like
this on PowerPC:
#include <complex>
using namespace std;
complex<float> bar(complex<float> C);
complex<float> foo(complex<float> C) {
return bar(C)*C;
}
which produces this:
define void @_Z4testSt7complexIfE(%"struct.std::complex"* noalias nocapture sret %agg.result, i64 %c.coerce) {
entry:
%ref.tmp = alloca i64, align 8
%tmpcast = bitcast i64* %ref.tmp to %"struct.std::complex"*
%c.sroa.0.0.extract.shift = lshr i64 %c.coerce, 32
%c.sroa.0.0.extract.trunc = trunc i64 %c.sroa.0.0.extract.shift to i32
%0 = bitcast i32 %c.sroa.0.0.extract.trunc to float
%c.sroa.2.0.extract.trunc = trunc i64 %c.coerce to i32
%1 = bitcast i32 %c.sroa.2.0.extract.trunc to float
call void @_Z3barSt7complexIfE(%"struct.std::complex"* nonnull sret %tmpcast, i64 %c.coerce)
%2 = bitcast %"struct.std::complex"* %agg.result to i64*
%3 = load i64, i64* %ref.tmp, align 8
store i64 %3, i64* %2, align 4 ; <--- ***** THIS SHOULD NOT BE HERE ****
%_M_value.realp.i.i = getelementptr inbounds %"struct.std::complex", %"struct.std::complex"* %agg.result, i64 0, i32 0, i32 0
%4 = lshr i64 %3, 32
%5 = trunc i64 %4 to i32
%6 = bitcast i32 %5 to float
%_M_value.imagp.i.i = getelementptr inbounds %"struct.std::complex", %"struct.std::complex"* %agg.result, i64 0, i32 0, i32 1
%7 = trunc i64 %3 to i32
%8 = bitcast i32 %7 to float
%mul_ad.i.i = fmul fast float %6, %1
%mul_bc.i.i = fmul fast float %8, %0
%mul_i.i.i = fadd fast float %mul_ad.i.i, %mul_bc.i.i
%mul_ac.i.i = fmul fast float %6, %0
%mul_bd.i.i = fmul fast float %8, %1
%mul_r.i.i = fsub fast float %mul_ac.i.i, %mul_bd.i.i
store float %mul_r.i.i, float* %_M_value.realp.i.i, align 4
store float %mul_i.i.i, float* %_M_value.imagp.i.i, align 4
ret void
}
the problem here is not just that the i64 store is unnecessary, but also that
it blocks further backend optimizations of the other uses of that i64 value in
the backend.
In the future, we might want to add a special case for handling smaller
accesses (e.g. using a bit vector) if the map mechanism turns out to be
noticeably inefficient. A sorted vector is also a possible replacement for the
map for small numbers of tracked intervals.
Differential Revision: http://reviews.llvm.org/D18586
llvm-svn: 273559
|
| |
|
|
| |
llvm-svn: 273523
|
| |
|
|
|
|
| |
This fixes PR28269.
llvm-svn: 273521
|
| |
|
|
|
|
| |
Spotted during random inspection.
llvm-svn: 273512
|
| |
|
|
|
|
| |
Found by gcc 6.
llvm-svn: 273402
|
| |
|
|
|
|
| |
Found by gcc 6.
llvm-svn: 273303
|
| |
|
|
| |
llvm-svn: 273163
|
| |
|
|
|
|
|
|
| |
This reverts commit r273160, reapplying r273132.
RecursivelyDeleteTriviallyDeadInstructions cannot be called on a
parentless Instruction.
llvm-svn: 273162
|
| |
|
|
|
|
|
|
| |
This reverts commit r273132.
Breaks multiple test under /llvm/test:Transforms (e.g.
llvm/test:Transforms/LoopIdiom/basic.ll.test) under asan.
llvm-svn: 273160
|
| |
|
|
| |
llvm-svn: 273149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove dependency of the evalution order of function arguments, which
is unspecified.
The following test previously failed when built with GCC (but succeded
when built with Clang):
; RUN: opt -sroa -S < %s | FileCheck %s
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
%A = type {i16}
@a = global %A* null
@b = global i16 0
; CHECK-LABEL: @f1(
; CHECK: alloca %A
; CHECK-NEXT: extractvalue %A
; CHECK-NEXT: getelementptr inbounds %A
define void @f1 (%A %a) {
%1 = alloca %A
store %A %a, %A* %1
%2 = load i16, i16* @b
%3 = icmp ne i16 %2, 0
br i1 %3, label %bb1, label %bb2
bb1:
store %A* %1, %A** @a
br label %bb2
bb2:
ret void
}
Patch by David Stenberg.
Differential Revision: http://reviews.llvm.org/D21226
llvm-svn: 273144
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a store has been eliminated, when making sure that the
instruction iterator points to a valid instruction, dbg intrinsics are
now ignored as a new instruction.
Patch by Henric Karlsson.
Reviewed by Daniel Berlin.
Differential Revision: http://reviews.llvm.org/D21076
llvm-svn: 273141
|
| |
|
|
|
|
|
|
|
|
| |
Removing dead instructions requires remembering which operands have
already been removed. RecursivelyDeleteTriviallyDeadInstructions has
this logic, don't partially reimplement it in LoopIdiomRecognize.
This fixes PR28196.
llvm-svn: 273132
|
| |
|
|
|
|
|
| |
Use an APInt to handle pointers of arbitrary width, let
accumulateConstantOffset handle overflow issues.
llvm-svn: 273126
|
| |
|
|
| |
llvm-svn: 273118
|
| |
|
|
|
|
|
|
|
|
|
| |
Change the underlying offset and comparisons to use int64_t instead of
uint64_t.
Patch by River Riddle!
Differential Revision: http://reviews.llvm.org/D21499
llvm-svn: 273105
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a functional change for LLE and LDist. The other clients (LV,
LVerLICM) already had this explicitly enabled.
The temporary boolean parameter to LAA is removed that allowed turning
off speculation of symbolic strides. This makes LAA's caching interface
LAA::getInfo only take the loop as the parameter. This makes the
interface more friendly to the new Pass Manager.
The flag -enable-mem-access-versioning is moved from LV to a LAA which
now allows turning off speculation globally.
llvm-svn: 273064
|
| |
|
|
|
|
|
|
| |
performance-unnecessary-value-param.
Contains some manual fixes. No functionality change intended.
llvm-svn: 273047
|
| |
|
|
|
|
|
|
|
| |
This is indeed a much cleaner approach (thanks to Daniel Berlin
for pointing out), and also David/Sean for review.
Differential Revision: http://reviews.llvm.org/D21454
llvm-svn: 273032
|
| |
|
|
| |
llvm-svn: 273030
|
| |
|
|
| |
llvm-svn: 273023
|
| |
|
|
|
|
| |
That's the idiomatic LLVM pattern.
llvm-svn: 272981
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass manager passes' `run` methods.
This removes a bunch of SFINAE goop from the pass manager and just
requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead
argument. This is a small price to pay for the simplicity of the system
as a whole, despite the noise that changing it causes at this stage.
This will also helpfull allow us to make the signature of the run
methods much more flexible for different kinds af passes to support
things like intelligently updating the pass's progression over IR units.
While this touches many, many, files, the changes are really boring.
Mostly made with the help of my trusty perl one liners.
Thanks to Sean and Hal for bouncing ideas for this with me in IRC.
llvm-svn: 272978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is still NFCI, so the list of clients that allow symbolic stride
speculation does not change (yes: LV and LoopVersioningLICM, no: LLE,
LDist). However since the symbolic strides are now managed by LAA
rather than passed by client a new bool parameter is used to enable
symbolic stride speculation.
The existing test Transforms/LoopVectorize/version-mem-access.ll checks
that stride speculation is performed for LV.
The previously added test Transforms/LoopLoadElim/symbolic-stride.ll
ensures that no speculation is performed for LLE.
The next patch will change the functionality and turn on symbolic stride
speculation in all of LAA's clients and remove the bool parameter.
llvm-svn: 272970
|