Part of the assert has been left active for further debugging.
The other part has been turned into a stat for tracking for the
moment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292583 91177308-0d34-0410-b5e6-96231b3b80d8
This can prove that:
extern int f;
int g() {
int x = 0;
for (int i = 0; i < 365; ++i) {
x /= f;
}
return x;
}
always returns zero. Thanks to Sanjoy for confirming this
transformation actually made sense (bugs are mine).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292531 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In case of non-alloca pointers, we check for whether it is a pointer
from malloc-like calls and it is not captured. In such case, we can
promote the pointer, as the caller will have no way to access this pointer
even if there is unwinding in middle of the loop.
Reviewers: hfinkel, sanjoy, reames, eli.friedman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28834
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292510 91177308-0d34-0410-b5e6-96231b3b80d8
Type identifiers are exported by:
- Adding coarse-grained information about how to test the type
identifier to the summary.
- Creating symbols in the object file (aliases and absolute symbols)
containing fine-grained information about the type identifier.
Differential Revision: https://reviews.llvm.org/D28424
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292462 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the vectorizer to explicitly use the loopsimplify and lcssa utils,
instead of "requiring" the transformations as if they were analyses.
This is not NFC, since it changes the LCSSA behavior - we no longer run LCSSA
for all loops, but rather only for the loops we expect to modify.
Differential Revision: https://reviews.llvm.org/D28868
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292456 91177308-0d34-0410-b5e6-96231b3b80d8
Mostly straightforward changes; we just didn't do the computation before.
One sort of interesting change in LoopUnroll.cpp: we weren't handling
dominance for children of the loop latch correctly, but
foldBlockIntoPredecessor hid the problem for complete unrolling.
Currently punting on loop peeling; made some minor changes to isolate
that problem to LoopUnrollPeel.cpp.
Adds a flag -unroll-verify-domtree; it verifies the domtree immediately
after we finish updating it. This is on by default for +Asserts builds.
Differential Revision: https://reviews.llvm.org/D28073
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292447 91177308-0d34-0410-b5e6-96231b3b80d8
We currently check whether a reduction has a single outside user. We don't
really need to require that - we just need to make sure a single value is
used externally. The number of external users of that value shouldn't actually
matter.
Differential Revision: https://reviews.llvm.org/D28830
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292424 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on D28777 - we don't need to handle 'all element' shuffles inside InstCombiner::visitCallInst as InstCombiner::SimplifyDemandedVectorElts will do everything we need.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292365 91177308-0d34-0410-b5e6-96231b3b80d8
follow LLVM's naming conventions while I'm here.
Again, sorry I didn't spot this earlier to coalesce with other cleanup
changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292333 91177308-0d34-0410-b5e6-96231b3b80d8
deleted.
I've expanded its test coverage a bit including adding one test that
will crash clearly without this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292332 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Partial unrolling should have separate threshold with full unrolling.
Reviewers: efriedma, mzolotukhin
Reviewed By: efriedma, mzolotukhin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28831
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292293 91177308-0d34-0410-b5e6-96231b3b80d8
unique exit block if available rather than rolling it ourselves.
This is a little disappointing because that helper doesn't do anything
clever to short-circuit the (surprisingly expensive) computation of all
exit blocks. What's worse is that the way we compute this is hopelessly,
hilariously inefficient. We're literally computing the same information
two different ways and multiple times each way:
- hasDedicatedExits computes the exit block set and then looks at the
predecessors of each
- getExitingBlocks computes the set of loop blocks which have exiting
successors
- getUniqueExitBlock(s) computes the set of non-loop blocks reached from
loop blocks (sound familiar?)
Anyways, at some point we should clean all of this up in the LoopInfo
API, but for now just simplifying the user I'm about to touch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292282 91177308-0d34-0410-b5e6-96231b3b80d8
I hope that for any code, it is changed only with good reason and only
when the author knows what they are doing...
There is of course good reason to comment here about the subtlety of the
process, and I've left that comment in tact.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292275 91177308-0d34-0410-b5e6-96231b3b80d8
instead of members.
No state was being provided by the object so this seems strictly
simpler.
I've also tried to improve the name and comments for the functions to
more thoroughly document what they are doing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292274 91177308-0d34-0410-b5e6-96231b3b80d8
that we know has exactly one element when all we are going to do is get
that one element out of it.
Instead, pass around that one element.
There are more simplifications to come in this code...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292273 91177308-0d34-0410-b5e6-96231b3b80d8
conventions more conistently before hacking on this code to integrate
nicely with new PM's loop pass infrastructure. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292272 91177308-0d34-0410-b5e6-96231b3b80d8
Add missing fabs(fpext) optimzation that worked with the call,
and also fixes it creating a second fpext when there were multiple
uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292172 91177308-0d34-0410-b5e6-96231b3b80d8
It's not clear what 'First' and 'Second' mean, so use 'Inner' and 'Outer'
to match foldShiftedShift() and add comments with formulas, so it's easier
to see what's going on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292153 91177308-0d34-0410-b5e6-96231b3b80d8
