| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 315728
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves some common utility functions out of IPSCCP and makes them
available globally. The functions determine if interprocedural data-flow
analyses can propagate information through function returns, arguments, and
global variables.
Differential Revision: https://reviews.llvm.org/D37638
llvm-svn: 315719
|
|
|
|
|
|
| |
instructions
llvm-svn: 315718
|
|
|
|
| |
llvm-svn: 315709
|
|
|
|
| |
llvm-svn: 315703
|
|
|
|
|
|
|
| |
The backend should be prepared for this transform after:
https://reviews.llvm.org/rL311731
llvm-svn: 315701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In RS4GC it is possible that a base pointer is contained in a vector that
has undergone a bitcast from one element-pointertype to another. We teach
RS4GC how to look through bitcasts of vector types when looking for a base
pointer.
Reviewers: anna
Reviewed By: anna
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38849
llvm-svn: 315694
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
addressing mode"
Significantly reduces performancei (~30%) of gipfeli
(https://github.com/google/gipfeli)
I have not yet managed to reproduce this regression with the open-source
version of the benchmark on github, but will work with others to get a
reproducer to you later today.
llvm-svn: 315680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch fixes the crash from https://bugs.llvm.org/show_bug.cgi?id=34659 and https://bugs.llvm.org/show_bug.cgi?id=34833.
Reviewers: rnk, majnemer
Reviewed By: rnk, majnemer
Subscribers: majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D38223
llvm-svn: 315677
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 315640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds processing of binary operations when the def of operands are in
the same block (i.e. local processing).
Earlier we bailed out in such cases (the bail out was introduced in rL252032)
because LVI at that time was more precise about context at the end of basic
blocks, which implied local def and use analysis didn't benefit CVP.
Since then we've added support for LVI in presence of assumes and guards. The
test cases added show how local def processing in CVP helps adding more
information to the ashr, sdiv, srem and add operators.
Note: processCmp which suffers from the same problem will
be handled in a later patch.
Reviewers: philip, apilipenko, SjoerdMeijer, hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38766
llvm-svn: 315634
|
|
|
|
|
|
| |
iteration check condition
llvm-svn: 315623
|
|
|
|
|
|
|
|
|
|
|
| |
IPSCCP.""
This reverts commit r315593: still affect two bots:
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/5308
http://green.lab.llvm.org/green/job/clang-stage2-configure-Rlto/21751/
llvm-svn: 315618
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up for the loop predication change 313981 to support ule, sle latch predicates.
Reviewed By: mkazantsev
Differential Revision: https://reviews.llvm.org/D38177
llvm-svn: 315616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is r315288 & r315294, which were reverted due to stage2 bot
failures.
Summary:
This updates the SCCP solver to use of the ValueElement lattice for
parameters, which provides integer range information. The range
information is used to remove unneeded icmp instructions.
For the following function, f() can be optimized to `ret i32 2` with
this change
source_filename = "sccp.c"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: norecurse nounwind readnone uwtable
define i32 @main() local_unnamed_addr #0 {
entry:
%call = tail call fastcc i32 @f(i32 1)
%call1 = tail call fastcc i32 @f(i32 47)
%add3 = add nsw i32 %call, %call1
ret i32 %add3
}
; Function Attrs: noinline norecurse nounwind readnone uwtable
define internal fastcc i32 @f(i32 %x) unnamed_addr #1 {
entry:
%c1 = icmp sle i32 %x, 100
%cmp = icmp sgt i32 %x, 300
%. = select i1 %cmp, i32 1, i32 2
ret i32 %.
}
attributes #1 = { noinline }
Reviewers: davide, sanjoy, efriedma, dberlin
Reviewed By: davide, dberlin
Subscribers: mcrosier, gberry, mssimpso, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D36656
llvm-svn: 315593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with
LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so
it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
llvm-svn: 315590
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38415
llvm-svn: 315551
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
|
|
|
|
|
|
| |
bots (NFC).
llvm-svn: 315519
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 315516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameterized emit() calls
Summary: This is not functional change to adopt new emit() API added in r313691.
Reviewed By: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38285
llvm-svn: 315476
|
|
|
|
| |
llvm-svn: 315448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control flow to successors
This patch fixes the miscompile that happens when PRE hoists loads across guards and
other instructions that don't always pass control flow to their successors. PRE is now prohibited
to hoist across such instructions because there is no guarantee that the load standing after such
instruction is still valid before such instruction. For example, a load from under a guard may be
invalid before the guard in the following case:
int array[LEN];
...
guard(0 <= index && index < LEN);
use(array[index]);
Differential Revision: https://reviews.llvm.org/D37460
llvm-svn: 315440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sinking of unordered atomic load into loop must be disallowed because it turns
a single load into multiple loads. The relevant section of the documentation
is: http://llvm.org/docs/Atomics.html#unordered, specifically the Notes for
Optimizers section. Here is the full text of this section:
> Notes for optimizers
> In terms of the optimizer, this **prohibits any transformation that
> transforms a single load into multiple loads**, transforms a store into
> multiple stores, narrows a store, or stores a value which would not be
> stored otherwise. Some examples of unsafe optimizations are narrowing
> an assignment into a bitfield, rematerializing a load, and turning loads
> and stores into a memcpy call. Reordering unordered operations is safe,
> though, and optimizers should take advantage of that because unordered
> operations are common in languages that need them.
Patch by Daniil Suchkov!
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D38392
llvm-svn: 315438
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRCE should not apply when the safe iteration range is proved to be empty.
In this case we do unneeded job creating pre/post loops and then never
go to the main loop.
This patch makes IRCE not apply to empty safe ranges, adds test for this
situation and also modifies one of existing tests where it used to happen
slightly.
Reviewed By: anna
Differential Revision: https://reviews.llvm.org/D38577
llvm-svn: 315437
|
|
|
|
|
|
|
|
| |
This fixes PR34908. Patch by Alex Crichton!
Differential Revision: https://reviews.llvm.org/D38765
llvm-svn: 315429
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 315383
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In the current implementation, we only have accurate profile count for standalone symbols. For inlined functions, we do not have entry count data because it's not available in LBR. In this patch, we use the first instruction's frequency to estimiate the function's entry count, especially for inlined functions. This may be inaccurate due to debug info in optimized code. However, this is a better estimate than the static 80/20 estimation we have in the current implementation.
Reviewers: tejohnson, davidxl
Reviewed By: tejohnson
Subscribers: sanjoy, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D38478
llvm-svn: 315369
|
|
|
|
|
|
|
|
|
| |
This reverts commit r315288. This is part of fixing segfault introduced
in:
http://green.lab.llvm.org/green/job/clang-stage2-configure-Rlto/21675/
llvm-svn: 315329
|
|
|
|
|
|
|
| |
This reverts commit r315294. Part of fixing seg fault introduced in:
http://green.lab.llvm.org/green/job/clang-stage2-configure-Rlto/21675/
llvm-svn: 315328
|
|
|
|
| |
llvm-svn: 315294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This updates the SCCP solver to use of the ValueElement lattice for
parameters, which provides integer range information. The range
information is used to remove unneeded icmp instructions.
For the following function, f() can be optimized to `ret i32 2` with
this change
source_filename = "sccp.c"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: norecurse nounwind readnone uwtable
define i32 @main() local_unnamed_addr #0 {
entry:
%call = tail call fastcc i32 @f(i32 1)
%call1 = tail call fastcc i32 @f(i32 47)
%add3 = add nsw i32 %call, %call1
ret i32 %add3
}
; Function Attrs: noinline norecurse nounwind readnone uwtable
define internal fastcc i32 @f(i32 %x) unnamed_addr #1 {
entry:
%c1 = icmp sle i32 %x, 100
%cmp = icmp sgt i32 %x, 300
%. = select i1 %cmp, i32 1, i32 2
ret i32 %.
}
attributes #1 = { noinline }
Reviewers: davide, sanjoy, efriedma, dberlin
Reviewed By: davide, dberlin
Subscribers: mcrosier, gberry, mssimpso, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D36656
llvm-svn: 315288
|
|
|
|
|
|
|
|
|
|
| |
handle memcmp expansion."
(fixed stability issues)
This reverts commit d6492333d3b478a1d88163315002022f8d5e58dc.
llvm-svn: 315281
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate inttype phi with inttoptr/ptrtoint.
This version fixed a bug in finding the matching
phi -- the order of the incoming blocks may be
different (triggered in self build on Windows).
A new test case is added.
llvm-svn: 315272
|
|
|
|
|
|
|
| |
Sync it up with the name of the class actually defined here. This has been
bothering me for a while...
llvm-svn: 315249
|
|
|
|
| |
llvm-svn: 315223
|
|
|
|
|
|
| |
simplifyDivRemOfSelectWithZeroOp (PR34856)
llvm-svn: 315130
|
|
|
|
|
|
|
|
|
| |
simplify code; NFCI
There's at least one bug here - this code can fail with vector types (PR34856).
It's also being called for FREM; I'm still trying to understand how that is valid.
llvm-svn: 315127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to be miscompiling Clang, as shown on two Windows bootstrap
bots:
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/7611
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/6870
Nothing else is in the blame list. Both emit errors on this valid code
in the Windows ucrt headers:
C:\...\ucrt\malloc.h:95:32: error: invalid operands to binary expression ('char *' and 'int')
_Ptr = (char*)_Ptr + _ALLOCA_S_MARKER_SIZE;
~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~
I am attempting to reproduce this now.
This reverts r315044
llvm-svn: 315108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: stripPointerCast is not reliably returning the value that's being type-casted. Instead it may look further at function attributes to further propagate the value. Instead of relying on stripPOintercast, the more reliable solution is to directly use the pointer to the promoted direct call.
Reviewers: tejohnson, davidxl
Reviewed By: tejohnson
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38603
llvm-svn: 315077
|
|
|
|
|
|
|
|
|
|
| |
handle memcmp expansion."
Still a few stability issues on windows.
This reverts commit 67e3db9bc121ba244e20337aabc7cf341a62b545.
llvm-svn: 315058
|
|
|
|
|
|
|
|
|
|
| |
handle memcmp expansion."
(fixed unit tests by making comparisons stable)
This reverts commit 1b2d359ce256fd6737da4e93833346a0bd6d7583.
llvm-svn: 315056
|
|
|
|
|
|
|
| |
Fixed ThinLTO bootstrap failure : track new
bitcast per incomingVal. Added new tests.
llvm-svn: 315044
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a vestige from the GCC-3 days, which disables IPO passes
when set. I don't think anybody actually uses it as there are
several IPO passes which still run with this flag set and
nobody complained/noticed. This reduces the delta between
current and new pass manager and allows us to easily review
the difference when we decide to flip the switch (or audit
which passes should run, FWIW).
llvm-svn: 315043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the extracted region has multiple exported data flows toward the same BB which is not included in the region, correct resotre instructions and PHI nodes won't be generated inside the exitStub. The solution is simply put the restore instructions right after the definition of output values instead of putting in exitStub.
Unittest for this bug is included.
Author: myhsu
Reviewers: chandlerc, davide, lattner, silvas, davidxl, wmi, kuhar
Subscribers: dberlin, kuhar, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37902
llvm-svn: 315041
|
|
|
|
| |
llvm-svn: 315040
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible for two modules to define the same set of external
symbols without causing a duplicate symbol error at link time,
as long as each of the symbols is a comdat member. So we cannot
use them as part of a unique id for the module.
Differential Revision: https://reviews.llvm.org/D38602
llvm-svn: 315026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can always eliminate the shift in: icmp gt/lt (shr X, C1), C2 --> icmp gt/lt X, C'
This patch was supposed to just be an efficiency improvement because we were doing this 3-step process to fold:
IC: Visiting: %c = icmp ugt i4 %s, 1
IC: ADD: %s = lshr i4 %x, 1
IC: ADD: %1 = udiv i4 %x, 2
IC: Old = %c = icmp ugt i4 %1, 1
New = <badref> = icmp uge i4 %x, 4
IC: ADD: %c = icmp uge i4 %x, 4
IC: ERASE %2 = icmp ugt i4 %1, 1
IC: Visiting: %c = icmp uge i4 %x, 4
IC: Old = %c = icmp uge i4 %x, 4
New = <badref> = icmp ugt i4 %x, 3
IC: ADD: %c = icmp ugt i4 %x, 3
IC: ERASE %2 = icmp uge i4 %x, 4
IC: Visiting: %c = icmp ugt i4 %x, 3
IC: DCE: %1 = udiv i4 %x, 2
IC: ERASE %1 = udiv i4 %x, 2
IC: DCE: %s = lshr i4 %x, 1
IC: ERASE %s = lshr i4 %x, 1
IC: Visiting: ret i1 %c
When we could go directly to canonical icmp form:
IC: Visiting: %c = icmp ugt i4 %s, 1
IC: Old = %c = icmp ugt i4 %s, 1
New = <badref> = icmp ugt i4 %x, 3
IC: ADD: %c = icmp ugt i4 %x, 3
IC: ERASE %1 = icmp ugt i4 %s, 1
IC: ADD: %s = lshr i4 %x, 1
IC: DCE: %s = lshr i4 %x, 1
IC: ERASE %s = lshr i4 %x, 1
IC: Visiting: %c = icmp ugt i4 %x, 3
...but then I noticed that the folds were incomplete too:
https://godbolt.org/g/aB2hLE
Here are attempts to prove the logic with Alive:
https://rise4fun.com/Alive/92o
Name: lshr_ult
Pre: ((C2 << C1) u>> C1) == C2
%sh = lshr i8 %x, C1
%r = icmp ult i8 %sh, C2
=>
%r = icmp ult i8 %x, (C2 << C1)
Name: ashr_slt
Pre: ((C2 << C1) >> C1) == C2
%sh = ashr i8 %x, C1
%r = icmp slt i8 %sh, C2
=>
%r = icmp slt i8 %x, (C2 << C1)
Name: lshr_ugt
Pre: (((C2+1) << C1) u>> C1) == (C2+1)
%sh = lshr i8 %x, C1
%r = icmp ugt i8 %sh, C2
=>
%r = icmp ugt i8 %x, ((C2+1) << C1) - 1
Name: ashr_sgt
Pre: (C2 != 127) && ((C2+1) << C1 != -128) && (((C2+1) << C1) >> C1) == (C2+1)
%sh = ashr i8 %x, C1
%r = icmp sgt i8 %sh, C2
=>
%r = icmp sgt i8 %x, ((C2+1) << C1) - 1
Name: ashr_exact_sgt
Pre: ((C2 << C1) >> C1) == C2
%sh = ashr exact i8 %x, C1
%r = icmp sgt i8 %sh, C2
=>
%r = icmp sgt i8 %x, (C2 << C1)
Name: ashr_exact_slt
Pre: ((C2 << C1) >> C1) == C2
%sh = ashr exact i8 %x, C1
%r = icmp slt i8 %sh, C2
=>
%r = icmp slt i8 %x, (C2 << C1)
Name: lshr_exact_ugt
Pre: ((C2 << C1) u>> C1) == C2
%sh = lshr exact i8 %x, C1
%r = icmp ugt i8 %sh, C2
=>
%r = icmp ugt i8 %x, (C2 << C1)
Name: lshr_exact_ult
Pre: ((C2 << C1) u>> C1) == C2
%sh = lshr exact i8 %x, C1
%r = icmp ult i8 %sh, C2
=>
%r = icmp ult i8 %x, (C2 << C1)
We did something similar for 'shl' in D28406.
Differential Revision: https://reviews.llvm.org/D38514
llvm-svn: 315021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In SamplePGO, when an indirect call is promoted in the profiled binary, before profile annotation, it will be promoted and inlined. For the original indirect call, the current implementation will not mark VP profile on it. This is an issue when profile becomes stale. This patch annotates VP prof on indirect calls during annotation.
Reviewers: tejohnson
Reviewed By: tejohnson
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D38477
llvm-svn: 315016
|