| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Run GDCE slightly later so that we don't have to repeat it
twice when preparing for Thin. Thanks to Mehdi for the suggestion.
llvm-svn: 314999
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inliner performs some kind of dead code elimination as it goes,
but there are cases that are not really caught by it. We might
at some point consider teaching the inliner about them, but it
is OK for now to run GlobalOpt + GlobalDCE in tandem as their
benefits generally outweight the cost, making the whole pipeline
faster.
This fixes PR34652.
Differential Revision: https://reviews.llvm.org/D38154
llvm-svn: 314997
|
| |
|
|
|
|
|
|
|
|
|
| |
When ignoring a load that participates in an interleaved group, make sure to
move a cast that needs to sink after it.
Testcase derived from reproducer of PR34743.
Differential Revision: https://reviews.llvm.org/D38338
llvm-svn: 314986
|
| |
|
|
|
|
|
|
|
|
| |
to handle memcmp expansion."""
broken test on windows
This reverts commit c91479518344fd1fc071c5bd5848f6eb83e53dca.
llvm-svn: 314985
|
| |
|
|
|
|
|
|
|
|
|
| |
exact X, C1), C2 --> icmp X, (C2<<C1)
There is a bot failure that appears to be related to this change:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/2117
...so reverting to confirm that and attempting to keep the bot green while investigating.
llvm-svn: 314984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to keep LastWidenRecipe updated after creating each recipe,
have tryToWiden() retrieve the last recipe of the current VPBasicBlock and check
if it's a VPWidenRecipe when attempting to extend its range. This ensures that
such extensions, optimized to maintain the original instruction order, do so
only when the instructions are to maintain their relative order. The latter does
not always hold, e.g., when a cast needs to sink to unravel first order
recurrence (r306884).
Testcase derived from reproducer of PR34711.
Differential Revision: https://reviews.llvm.org/D38339
llvm-svn: 314981
|
| |
|
|
|
|
| |
handle memcmp expansion.""
llvm-svn: 314980
|
| |
|
|
|
|
|
|
|
|
|
| |
handle memcmp expansion."
Breaks
clang-stage1-cmake-RA-incremental/llvm/test/Transforms/MergeICmps/X86/tuple-four-int8.ll
This reverts commit 3038c459d67f8898ffa295d54a013b280690abfa.
llvm-svn: 314972
|
| |
|
|
|
|
|
|
|
|
| |
We were using an i1 type and then zero extending to a vector. Instead just create the 0/1 directly as a ConstantInt with the correct type. No need to ask ConstantExpr to zero extend for us.
This bug is a bit tricky to hit because it requires us to visit a zext of an icmp that would normally be simplified to true/false, but that icmp hasnt' been visited yet. In the test case this zext and icmp were created by visiting a udiv and due to worklist ordering we got to the zext first.
Fixes PR34841.
llvm-svn: 314971
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansion.
Summary: This is to avoid e.g. merging two cheap icmps if the target is not going to expand to something nice later.
Reviewers: dberlin, spatel
Subscribers: davide, nemanjai
Differential Revision: https://reviews.llvm.org/D38232
llvm-svn: 314970
|
| |
|
|
| |
llvm-svn: 314961
|
| |
|
|
|
|
|
|
| |
We can support ashr similar to lshr, if we know that none of the shifted in bits are used. In that case SimplifyDemandedBits would normally convert it to lshr. But that conversion doesn't happen if the shift has additional users.
Differential Revision: https://reviews.llvm.org/D38521
llvm-svn: 314945
|
| |
|
|
| |
llvm-svn: 314936
|
| |
|
|
| |
llvm-svn: 314934
|
| |
|
|
|
|
|
|
|
|
|
|
| |
struct; NFCI
This is a follow-up to https://reviews.llvm.org/D38138.
I fixed the capitalization of some functions because we're changing those
lines anyway and that helped verify that we weren't accidentally dropping
any options by using default param values.
llvm-svn: 314930
|
| |
|
|
|
|
|
| |
(trial 2) Incoming val defined by terminator instruction which
also requires bitcasts can not be handled.
llvm-svn: 314928
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommitting r314517 with the fix for handling ConstantExpr.
Original commit message:
Currently, getGEPCost() returns TCC_FREE whenever a GEP is a legal addressing
mode in the target. However, since it doesn't check its actual users, it will
return FREE even in cases where the GEP cannot be folded away as a part of
actual addressing mode. For example, if an user of the GEP is a call
instruction taking the GEP as a parameter, then the GEP may not be folded in
isel.
llvm-svn: 314923
|
| |
|
|
| |
llvm-svn: 314906
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We have found some corner cases connected to range intersection where IRCE makes
a bad thing when the latch condition is unsigned. The fix for that will go as a follow up.
This patch temporarily disables IRCE for unsigned latch conditions until the issue is fixed.
The unsigned latch conditions were introduced to IRCE by rL310027.
Differential Revision: https://reviews.llvm.org/D38529
llvm-svn: 314881
|
| |
|
|
|
|
|
|
| |
create new sign bit compares instead of manipulating the constant. NFCI
Since we no longer had the direct constant compares, manipulating the constant seemeded less clear.
llvm-svn: 314830
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the buildbots are red, e.g.
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/2436/
> Summary:
> This patch tries to vectorize loads of consecutive memory accesses, accessed
> in non-consecutive or jumbled way. An earlier attempt was made with patch D26905
> which was reverted back due to some basic issue with representing the 'use mask' of
> jumbled accesses.
>
> This patch fixes the mask representation by recording the 'use mask' in the usertree entry.
>
> Change-Id: I9fe7f5045f065d84c126fa307ef6ebe0787296df
>
> Reviewers: mkuper, loladiro, Ayal, zvi, danielcdh
>
> Reviewed By: Ayal
>
> Subscribers: hans, mzolotukhin
>
> Differential Revision: https://reviews.llvm.org/D36130
llvm-svn: 314824
|
| |
|
|
| |
llvm-svn: 314807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch tries to vectorize loads of consecutive memory accesses, accessed
in non-consecutive or jumbled way. An earlier attempt was made with patch D26905
which was reverted back due to some basic issue with representing the 'use mask' of
jumbled accesses.
This patch fixes the mask representation by recording the 'use mask' in the usertree entry.
Change-Id: I9fe7f5045f065d84c126fa307ef6ebe0787296df
Reviewers: mkuper, loladiro, Ayal, zvi, danielcdh
Reviewed By: Ayal
Subscribers: hans, mzolotukhin
Differential Revision: https://reviews.llvm.org/D36130
llvm-svn: 314806
|
| |
|
|
|
|
|
|
| |
of pointer.
This allows us to remove a bunch of dereferences and only have a few dereferences at the call sites.
llvm-svn: 314762
|
| |
|
|
|
|
|
|
| |
compare of the APInts themselves.
Apparently this works by virtue of the fact that the pointers are pointers to the APInts stored inside of the ConstantInt objects. But I really don't think we should be relying on that.
llvm-svn: 314761
|
| |
|
|
| |
llvm-svn: 314740
|
| |
|
|
|
|
| |
icmp X, (C2<<C1)
llvm-svn: 314698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If the merged instruction is call instruction, we need to set the scope to the closes common scope between 2 locations, otherwise it will cause trouble when the call is getting inlined.
Reviewers: dblaikie, aprantl
Reviewed By: dblaikie, aprantl
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D37877
llvm-svn: 314694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This currently uses ConstantExpr to do its math, but as noted in a TODO it can all be done directly on APInt.
Reviewers: spatel, majnemer
Reviewed By: majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38440
llvm-svn: 314640
|
| |
|
|
|
|
|
|
|
|
|
|
| |
And follow-up r314585.
Leads to segfaults. I'll forward reproduction instructions to the patch
author.
Also, for a recommit, still add the original patch description.
Otherwise, it becomes really tedious to find out what a patch actually
does. The fact that it is a recommit with a fix is somewhat secondary.
llvm-svn: 314622
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
phase and other phases.
Summary: In SamplePGO ThinLTO compile phase, we will not invoke ICP as it may introduce confusion to the 2nd annotation. This patch extracted that logic and makes it clearer before profile annotation. In the mean time, we need to make function importing process both inlined callsites as well as not promoted indirect callsites.
Reviewers: tejohnson
Reviewed By: tejohnson
Subscribers: sanjoy, mehdi_amini, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D38094
llvm-svn: 314619
|
| |
|
|
|
|
| |
phi of ops users.
llvm-svn: 314612
|
| |
|
|
| |
llvm-svn: 314611
|
| |
|
|
| |
llvm-svn: 314610
|
| |
|
|
| |
llvm-svn: 314609
|
| |
|
|
|
|
| |
inlineCallInstruction. (NFC)
llvm-svn: 314601
|
| |
|
|
|
|
|
| |
Causes a segfault on a builtbot (and in our internal bootstrapping of
Clang). See Eli's response on the commit thread.
llvm-svn: 314589
|
| |
|
|
| |
llvm-svn: 314585
|
| |
|
|
| |
llvm-svn: 314579
|
| |
|
|
| |
llvm-svn: 314563
|