| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 272139
|
| |
|
|
|
|
|
|
| |
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
llvm-svn: 272126
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21040
llvm-svn: 272009
|
| |
|
|
| |
llvm-svn: 271934
|
| |
|
|
| |
llvm-svn: 271932
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix LSRInstance::HoistInsertPosition() to check the original insert
position block first for a canonical insertion point that is dominated
by all inputs. This leads to SCEV being able to reuse more instructions
since it currently tracks the instructions it creates for reuse by
keeping a table of <Value, insert point> pairs.
Originally reviewed in http://reviews.llvm.org/D18001
Reviewers: atrick
Subscribers: llvm-commits, mzolotukhin, mcrosier
Differential Revision: http://reviews.llvm.org/D18480
llvm-svn: 271929
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This hasn't been caught before because it requires noalias or similarly
strong alias analysis to actually reproduce.
Fixes http://llvm.org/PR27952 .
Reviewers: hfinkel, sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20944
llvm-svn: 271858
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are some rough corners, since the new pass manager doesn't have
(as far as I can tell) LoopSimplify and LCSSA, so I've updated the
tests to run them separately in the old pass manager in the lit tests.
We also don't have an equivalent for AU.setPreservesCFG() in the new
pass manager, so I've left a FIXME.
Reviewers: bogner, chandlerc, davide
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D20783
llvm-svn: 271846
|
| |
|
|
|
|
|
|
|
|
| |
It is an off-by-default option that no one seems to use[0], and given
that SCEV directly understands the overflow instrinsics there is no real
need for it anymore.
[0]: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098181.html
llvm-svn: 271845
|
| |
|
|
|
|
|
|
|
|
|
| |
heuristic.
In r270478, where I enabled the new heuristic I posted testing results,
which I got when explicitly passed the thresholds values via CL options.
However, setting the CL options init-values is not enough to change the
default values of thresholds, so I'm changing them in another place now.
llvm-svn: 271615
|
| |
|
|
|
|
|
|
|
| |
In preparation for porting to the new PM.
Patch by Jake VanAdrighem! (review mainly by me/Justin)
Differential Revision: http://reviews.llvm.org/D20610
llvm-svn: 271607
|
| |
|
|
| |
llvm-svn: 271601
|
| |
|
|
| |
llvm-svn: 271600
|
| |
|
|
|
|
|
| |
Another chapter in the story. GlobalsAA should be preserved, as
well as the CFG.
llvm-svn: 271307
|
| |
|
|
|
|
|
| |
When this pass was originally ported, AA wasn't available for the
new PM. Now it is, so we can cache properly.
llvm-svn: 271303
|
| |
|
|
|
|
| |
them. Auto upgrade to native unaligned store instructions.
llvm-svn: 271236
|
| |
|
|
|
|
|
|
|
|
|
| |
Since we already assert that the outgoing IR is in LCSSA, it is easy to
get misled into thinking that -indvars broke LCSSA if the incoming IR is
non-LCSSA. Checking this pre-condition will make such cases break in
more obvious ways.
Inspired by (but does _not_ fix) PR26682.
llvm-svn: 271196
|
| |
|
|
|
|
| |
This will be used later to port IndVarSimplify to the new pass manager.
llvm-svn: 271190
|
| |
|
|
|
|
| |
While here, add a FIXME for setPreserveCFG().
llvm-svn: 271159
|
| |
|
|
| |
llvm-svn: 271149
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
unused variables in Release mode:
BasicBlock *Header
unsigned OrigCount
put under DEBUG
From: Evgeny Stupachenko <evstupac@gmail.com>
llvm-svn: 271076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Unroll factor (Count) calculations moved to a new function.
Early exits on pragma and "-unroll-count" defined factor added.
New type of unrolling "Force" introduced (previously used implicitly).
New unroll preference "AllowRemainder" introduced and set "true" by default.
(should be set to false for architectures that suffers from it).
Reviewers: hfinkel, mzolotukhin, zzheng
Differential Revision: http://reviews.llvm.org/D19553
From: Evgeny Stupachenko <evstupac@gmail.com>
llvm-svn: 271071
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: dberlin, reames, george.burgess.iv
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D20743
llvm-svn: 271034
|
| |
|
|
|
|
| |
No functionality change intended, maybe a tiny performance improvement.
llvm-svn: 270997
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we consider that each constant has itself as a base value. I.e "base(const) = const".
This introduces couple of problems when we are trying to avoid reporting constants in statepoint live sets:
1. When querying "base( phi(const1, const2) )" we will get "phi(const1, const2)" as a base pointer. Since
it's not a constant we will record it in a stack map. However on practice we don't want this to happen
(constant are never relocated).
2. base( phi(const, gc ptr) ) = phi( const, base(gc ptr) ). This particular case imposes challenge on our
runtime - we don't expect to see constant base pointers other than null. This problems can be avoided
by treating all constant as if they were derived from null pointer base. I.e in a first case we will
not include constant pointer in a stack map at all. In a second case we will get "phi(null, base(gc ptr))"
as a base pointer which is a lot more convenient.
Differential Revision: http://reviews.llvm.org/D20584
llvm-svn: 270993
|
| |
|
|
|
|
|
|
|
| |
Condition might be simplified to a Constant, but it doesn't have to be
ConstantInt, so we should dyn_cast, instead of cast.
This fixes PR27886.
llvm-svn: 270924
|
| |
|
|
|
|
|
|
|
| |
An exception could prevent a store from occurring but MemCpyOpt's
callslot optimization would fire anyway, causing the store to occur.
This fixes PR27849.
llvm-svn: 270892
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It is unsafe to hoist a load before a function call which may throw, the
throw might prevent a pointer dereference.
Likewise, it is unsafe to sink a store after a call which may throw.
The caller might be able to observe the difference.
This fixes PR27858.
llvm-svn: 270828
|
| |
|
|
|
|
| |
No functional change is intended.
llvm-svn: 270824
|
| |
|
|
|
|
|
|
| |
the same places that the SSE/SSE2 storeu intrinsics appear.
I don't really know how to test this. Just seemed like we should be consistent.
llvm-svn: 270819
|
| |
|
|
| |
llvm-svn: 270815
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
After this change, we do the expected thing for cases like
```
Check0Passed = /* range check IRCE can optimize */
Check1Passed = /* range check IRCE can optimize */
if (!(Check0Passed && Check1Passed))
throw_Exception();
```
llvm-svn: 270804
|
| |
|
|
|
|
|
| |
This will later hold more general logic to parse conjunctions of range
checks.
llvm-svn: 270802
|
| |
|
|
| |
llvm-svn: 270798
|
| |
|
|
|
|
|
| |
While here, convert the logic of the pass to use static function(s).
This is in preparation for porting this pass to the new PM.
llvm-svn: 270734
|
| |
|
|
|
|
| |
long time.
llvm-svn: 270677
|
| |
|
|
| |
llvm-svn: 270647
|
| |
|
|
|
|
|
|
| |
more time.
This reverts commit r270577.
llvm-svn: 270630
|
| |
|
|
|
|
| |
Make `GuardWideningImpl::RangeCheck` into a class and add accessors.
llvm-svn: 270611
|
| |
|
|
|
|
|
| |
This is better layering, since the caller needs to check if the index
was an add-rec anyway.
llvm-svn: 270582
|
| |
|
|
|
|
|
|
| |
analysis by default.
Chromium builds are still hitting the assert in PR27874.
llvm-svn: 270577
|
| |
|
|
|
|
|
|
|
| |
default.""
This reverts commit r270512 and reapplies r270478. Originally it caused
PR27847, but it was fixed in r270517.
llvm-svn: 270518
|
| |
|
|
|
|
| |
This caused PR27847.
llvm-svn: 270512
|
| |
|
|
|
|
|
|
|
|
| |
This changes IRCE to optimize uses, and not branches. This change is
NFCI since the uses we do inspect are in practice only ever going to be
the condition use in conditional branches; but this flexibility will
later allow us to analyze more complex expressions than just a direct
branch on a range check.
llvm-svn: 270500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch turns on LoopUnrollAnalyzer by default. To mitigate compile
time regressions, I chose very conservative thresholds for now. Later we
can make them more aggressive, but it might require being smarter in
which loops we're optimizing. E.g. currently the biggest issue is that
with more agressive thresholds we unroll many cold loops, which
increases compile time for no performance benefit (performance of those
loops is improved, but it doesn't matter since they are cold).
Test results for compile time(using 4 samples to reduce noise):
```
MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes 5.19%
SingleSource/Benchmarks/Polybench/medley/reg_detect/reg_detect 4.19%
MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 3.39%
MultiSource/Applications/JM/lencod/lencod 1.47%
MultiSource/Benchmarks/Fhourstones-3_1/fhourstones3_1 -6.06%
```
I didn't see any performance changes in the testsuite, but it improves
some internal tests.
Reviewers: hfinkel, chandlerc
Subscribers: llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D20482
llvm-svn: 270478
|
| |
|
|
|
|
|
|
| |
The InductiveRangeCheck struct is only five words long; so passing these
around value is fine. The allocator makes the code look more complex
than it is.
llvm-svn: 270309
|
| |
|
|
| |
llvm-svn: 270308
|
| |
|
|
|
|
|
|
|
|
|
| |
I had used `std::remove_if` under the assumption that it moves the
predicate matching elements to the end, but actaully the elements
remaining towards the end (after the iterator returned by
`std::remove_if`) are indeterminate. Fix the bug (and make the code
more straightforward) by using a temporary SmallVector, and add a test
case demonstrating the issue.
llvm-svn: 270306
|
| |
|
|
|
|
| |
Inline getAnalysisUsage() while I'm here.
llvm-svn: 270231
|
| |
|
|
| |
llvm-svn: 270228
|