| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These heuristics are sufficient for enabling IV chains by
default. Performance analysis has been done for i386, x86_64, and
thumbv7. The optimization is rarely important, but can significantly
speed up certain cases by eliminating spill code within the
loop. Unrolled loops are prime candidates for IV chains. In many
cases, the final code could still be improved with more target
specific optimization following LSR. The goal of this feature is for
LSR to make the best choice of induction variables.
Instruction selection may not completely take advantage of this
feature yet. As a result, there could be cases of slight code size
increase.
Code size can be worse on x86 because it doesn't support postincrement
addressing. In fact, when chains are formed, you may see redundant
address plus stride addition in the addressing mode. GenerateIVChains
tries to compensate for the common cases.
On ARM, code size increase can be mitigated by using postincrement
addressing, but downstream codegen currently misses some opportunities.
llvm-svn: 147826
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After collecting chains, check if any should be materialized. If so,
hide the chained IV users from the LSR solver. LSR will only solve for
the head of the chain. GenerateIVChains will then materialize the
chained IV users by computing the IV relative to its previous value in
the chain.
In theory, chained IV users could be exposed to LSR's solver. This
would be considerably complicated to implement and I'm not aware of a
case where we need it. In practice it's more important to
intelligently prune the search space of nontrivial loops before
running the solver, otherwise the solver is often forced to prune the
most optimal solutions. Hiding the chained users does this well, so
that LSR is more likely to find the best IV for the chain as a whole.
llvm-svn: 147801
|
| |
|
|
|
|
|
|
| |
This collects a set of IV uses within the loop whose values can be
computed relative to each other in a sequence. Following checkins will
make use of this information.
llvm-svn: 147797
|
| |
|
|
| |
llvm-svn: 147785
|
| |
|
|
|
|
| |
This will be more important as we extend the LSR pass in ways that don't rely on the formula solver. In particular, we need it for constructing IV chains.
llvm-svn: 147724
|
| |
|
|
|
|
|
|
| |
LoopSimplify may not run on some outer loops, e.g. because of indirect
branches. SCEVExpander simply cannot handle outer loops with no preheaders.
Fixes rdar://10655343 SCEVExpander segfault.
llvm-svn: 147718
|
| |
|
|
| |
llvm-svn: 147711
|
| |
|
|
| |
llvm-svn: 147707
|
| |
|
|
| |
llvm-svn: 146459
|
| |
|
|
|
|
|
|
| |
Since we're not rewriting IVs in other loops, there's not much reason
to consider their stride when generating formulae.
This should reduce the number of useless formulas considered by LSR.
llvm-svn: 146302
|
| |
|
|
|
|
|
|
|
| |
It's always good to prune early, but formulae that are unsatisfactory
in their own right need to be removed before running any other pruning
heuristics. We easily avoid generating such formulae, but we need them
as an intermediate basis for forming other good formulae.
llvm-svn: 145906
|
| |
|
|
| |
llvm-svn: 145154
|
| |
|
|
| |
llvm-svn: 144721
|
| |
|
|
|
|
| |
Someone more familiar with LSR should double-check that the extra cast is actually doing the right thing in the overflow cases; I'm not completely confident that's that case.
llvm-svn: 141916
|
| |
|
|
|
|
|
| |
I'm not sure we will need it in the long run, but the option is
currently useful for checking if the output of LSR is "clean".
llvm-svn: 141634
|
| |
|
|
|
|
| |
Fixes rdar://problem/5064068
llvm-svn: 141442
|
| |
|
|
|
|
|
|
| |
This handles the case in which LSR rewrites an IV user that is a phi and
splits critical edges originating from a switch.
Fixes <rdar://problem/6453893> LSR is not splitting edges "nicely"
llvm-svn: 141059
|
| |
|
|
| |
llvm-svn: 140769
|
| |
|
|
|
|
|
|
| |
Rewriting the entire loop nest now requires -enable-lsr-nested.
See PR11035 for some performance data.
A few unit tests specifically test nested LSR, and are now under a flag.
llvm-svn: 140762
|
| |
|
|
|
|
|
| |
Disabling aggressive LSR saves compilation time, and with the new
indvars behavior usually improves performance.
llvm-svn: 140590
|
| |
|
|
|
|
| |
previous checkin.
llvm-svn: 140583
|
| |
|
|
|
|
|
|
| |
The minor bug heuristic was noticed by inspection. I added the
isLoser/isValid helpers because they will become more
important with subsequent checkins.
llvm-svn: 140580
|
| |
|
|
|
|
|
| |
No test case. Noticed by inspection and I doubt it ever affects the
outcome of the overall heuristic, let alone final codegen.
llvm-svn: 140431
|
| |
|
|
|
|
| |
proper function to do it.
llvm-svn: 138550
|
| |
|
|
|
|
| |
getFirstNonPHI so that it will skip over the landingpad instructions as well.
llvm-svn: 138537
|
| |
|
|
| |
llvm-svn: 138481
|
| |
|
|
| |
llvm-svn: 135654
|
| |
|
|
|
|
| |
rdar://9786536
llvm-svn: 135650
|
| |
|
|
|
|
| |
rdar://9786536
llvm-svn: 135644
|
| |
|
|
| |
llvm-svn: 135375
|
| |
|
|
| |
llvm-svn: 135251
|
| |
|
|
| |
llvm-svn: 133992
|
| |
|
|
| |
llvm-svn: 133518
|
| |
|
|
|
|
| |
This fixes PR9845.
llvm-svn: 131919
|
| |
|
|
|
|
|
|
|
|
| |
No functionality enabled by default. Use -disable-iv-rewrite.
Extended IVUsers to keep track of the phi that represents the users' IV.
Added the WidenIV transform to replace a narrow IV with a wide IV
by doing a one-for-one replacement of IV users instead of expanding the
SCEV expressions. [sz]exts are removed and truncs are inserted.
llvm-svn: 131744
|
| |
|
|
|
|
|
| |
of the comparison, so that the resulting expression is fully
normalized. This fixes PR9939.
llvm-svn: 131576
|
| |
|
|
|
|
|
|
| |
model constants which can be added to base registers via add-immediate
instructions which don't require an additional register to materialize
the immediate.
llvm-svn: 130743
|
| |
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129558
|
| |
|
|
| |
llvm-svn: 129419
|
| |
|
|
| |
llvm-svn: 129403
|
| |
|
|
|
|
|
|
|
| |
Now that we have a first-class way to represent unaligned loads, the unaligned
load intrinsics are superfluous.
First part of <rdar://problem/8460511>.
llvm-svn: 129401
|
| |
|
|
|
|
| |
PHINode::Create() giving the (known or expected) number of operands.
llvm-svn: 128537
|
| |
|
|
| |
llvm-svn: 128535
|
| |
|
|
|
|
|
|
|
| |
properties.
Added the self-wrap flag for SCEV::AddRecExpr.
A slew of temporary FIXMEs indicate the intention of the no-self-wrap flag
without changing behavior in this revision.
llvm-svn: 127590
|
| |
|
|
|
|
| |
iv-users twice.
llvm-svn: 125318
|
| |
|
|
| |
llvm-svn: 125257
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Natural Loop Information
Loop Pass Manager
Canonicalize natural loops
Scalar Evolution Analysis
Loop Pass Manager
Induction Variable Users
Canonicalize natural loops
Induction Variable Users
Loop Strength Reduction
into this:
Scalar Evolution Analysis
Loop Pass Manager
Canonicalize natural loops
Induction Variable Users
Loop Strength Reduction
This fixes <rdar://problem/8869639>. I also filed PR9184 on doing this sort of
thing automatically, but it seems easier to just change the ordering of the
passes if this is the only case.
llvm-svn: 125254
|
| |
|
|
|
|
|
|
| |
the active loop. This is generally desirable, and it avoids trouble
in situations such as the testcase in PR9123, though the failure
mode depends on use-list order, so it is infeasible to test.
llvm-svn: 125065
|
| |
|
|
|
|
| |
dominance and post-dominance frontiers.
llvm-svn: 123725
|
| |
|
|
|
|
| |
so that Dominators.h is *just* domtree. Also prune #includes a bit.
llvm-svn: 122714
|