| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:
- Not determined by use-list order.
- Initially guarantees RPO order of block and subloops.
- Linear in the number of CFG edges.
- Nonrecursive.
I didn't want to change the LoopInfo API yet, so the block lists are
still inclusive. This seems strange to me, and it means that building
LoopInfo is not strictly linear, but it may not be a problem in
practice. At least the block lists start out in RPO order now. In the
future we may add an attribute or wrapper analysis that allows other
passes to assume RPO order.
The primary motivation of this work was not to optimize LoopInfo, but
to allow reproducing performance issues by decomposing the compilation
stages. I'm often unable to do this with the current LoopInfo, because
the loop tree order determines Loop pass order. Serializing the IR
tends to invert the order, which reverses the optimization order. This
makes it nearly impossible to debug interdependent loop optimizations
such as LSR.
I also believe this will provide more stable performance results across time.
llvm-svn: 158790
|
|
|
|
|
|
|
|
|
| |
The implementation only needs inclusion from LoopInfo.cpp and
MachineLoopInfo.cpp. Clients of the interface should only include the
interface. This makes the interface readable and speeds up rebuilds
after modifying the implementation.
llvm-svn: 158787
|
|
|
|
|
|
|
|
| |
Take this opportunity to generalize the indirectbr bailout logic for
loop transformations. CFG transformations will never get indirectbr
right, and there's no point trying.
llvm-svn: 154386
|
|
|
|
|
|
|
|
|
| |
into Analysis as a standalone function, since there's no need for
it to be in VMCore. Also, update it to use isKnownNonZero and
other goodies available in Analysis, making it more precise,
enabling more aggressive optimization.
llvm-svn: 146610
|
|
|
|
|
|
| |
SCEV should now be used for trip count analysis, not LoopInfo.
llvm-svn: 145262
|
|
|
|
|
|
|
|
|
|
|
| |
The loop tree's inclusive block lists are painful and expensive to
update. (I have no idea why they're inclusive). The design was
supposed to handle this case but the implementation missed it and my
unit tests weren't thorough enough.
Fixes PR11335: loop unroll update.
llvm-svn: 144970
|
|
|
|
|
|
| |
Fixes an oversight, and adds verification to catch it in the unloop.ll tests.
llvm-svn: 138622
|
|
|
|
| |
llvm-svn: 138025
|
|
|
|
|
|
| |
instruction should be marked as potentially reading and/or writing memory.
llvm-svn: 137863
|
|
|
|
|
|
| |
write to memory.) Marking it as such makes some checks for immobility go away.
llvm-svn: 137655
|
|
|
|
| |
llvm-svn: 137628
|
|
|
|
|
|
| |
when building with assertions disabled.
llvm-svn: 137460
|
|
|
|
|
|
|
|
|
| |
ancestor loops.
I have a unit test that depends on scev-unroll, which unfortunately
isn't checked in. But I will check it in when I can.
llvm-svn: 137341
|
|
|
|
| |
llvm-svn: 137317
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An algorithm for incrementally updating LoopInfo within a
LoopPassManager. The incremental update should be extremely cheap in
most cases and can be used in places where it's not feasible to
regenerate the entire loop forest.
- "Unloop" is a node in the loop tree whose last backedge has been removed.
- Perform reverse dataflow on the block inside Unloop to propagate the
nearest loop from the block's successors.
- For reducible CFG, each block in unloop is visited exactly
once. This is because unloop no longer has a backedge and blocks
within subloops don't change parents.
- Immediate subloops are summarized by the nearest loop reachable from
their exits or exits within nested subloops.
- At completion the unloop blocks each have a new parent loop, and
each immediate subloop has a new parent.
llvm-svn: 137276
|
|
|
|
| |
llvm-svn: 137195
|
|
|
|
| |
llvm-svn: 136857
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LoopPassManager. The incremental update should be extremely cheap in
most cases and can be used in places where it's not feasible to
regenerate the entire loop forest.
- "Unloop" is a node in the loop tree whose last backedge has been removed.
- Perform reverse dataflow on the block inside Unloop to propagate the
nearest loop from the block's successors.
- For reducible CFG, each block in unloop is visited exactly
once. This is because unloop no longer has a backedge and blocks
within subloops don't change parents.
- Immediate subloops are summarized by the nearest loop reachable from
their exits or exits within nested subloops.
- At completion the unloop blocks each have a new parent loop, and
each immediate subloop has a new parent.
llvm-svn: 136844
|
|
|
|
| |
llvm-svn: 136843
|
|
|
|
| |
llvm-svn: 119001
|
|
|
|
|
|
|
|
|
| |
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
|
|
|
|
|
|
| |
Loop::hasLoopInvariantOperands method. Remove
a useless and confusing Loop::isLoopInvariant(Instruction)
method, which didn't do what you thought it did.
No functionality change.
llvm-svn: 113133
|
|
|
|
|
|
| |
eliminate it.
llvm-svn: 109270
|
|
|
|
|
|
| |
the BlockTraits abstractions.
llvm-svn: 109268
|
|
|
|
| |
llvm-svn: 109045
|
|
|
|
| |
llvm-svn: 107967
|
|
|
|
| |
llvm-svn: 101376
|
|
|
|
|
|
|
| |
compute a set of reachable blocks for itself each time it is called, which
is fairly frequently.
llvm-svn: 98179
|
|
|
|
|
|
| |
as LCSSA no longer transforms such uses.
llvm-svn: 98033
|
|
|
|
| |
llvm-svn: 92772
|
|
|
|
|
|
|
|
| |
contains another loop, or an instruction. The loop form is
substantially more efficient on large loops than the typical
code it replaces.
llvm-svn: 91654
|
|
|
|
|
|
| |
avoid spurious failures. This fixes PR5758.
llvm-svn: 91147
|
|
|
|
| |
llvm-svn: 89426
|
|
|
|
| |
llvm-svn: 86565
|
|
|
|
|
|
| |
a separate helper function.
llvm-svn: 86159
|
|
|
|
|
|
|
|
| |
container of the blocks and do efficient lookups. This makes
isLoopSimplifyForm much faster on large loops, fixing a significant
compile-time issue in builds with assertions enabled.
llvm-svn: 84673
|
|
|
|
|
|
|
|
|
|
|
|
| |
the PassManager code into a regular verifyAnalysis method.
Also, reorganize loop verification. Make the LoopPass infrastructure
call verifyLoop as needed instead of having LoopInfo::verifyAnalysis
check every loop in the function after each looop pass. Add a new
command-line argument, -verify-loop-info, to enable the expensive
full checking.
llvm-svn: 82952
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that get created during loop unswitching, and fix SplitBlockPredecessors'
LCSSA updating code to create new PHIs instead of trying to just move
existing ones.
Also, optimize Loop::verifyLoop, since it gets called a lot. Use
searches on a sorted list of blocks instead of calling the "contains"
function, as is done in other places in the Loop class, since "contains"
does a linear search. Also, don't call verifyLoop from LoopSimplify or
LCSSA, as the PassManager is already calling verifyLoop as part of
LoopInfo's verifyAnalysis.
llvm-svn: 81221
|
|
|
|
|
|
| |
tests significantly.
llvm-svn: 81101
|
|
|
|
| |
llvm-svn: 80942
|
|
|
|
|
|
|
|
|
| |
that these passes are properly preserved.
Fix several transformation passes that claimed to preserve LoopSimplify
form but weren't.
llvm-svn: 80926
|
|
|
|
|
|
|
| |
LoopSimplify form, which is currently only available on Loops (and
not MachineLoops). Also, move the code out of the header file.
llvm-svn: 80923
|
|
|
|
| |
llvm-svn: 79838
|
|
|
|
|
|
| |
update all code that this affects.
llvm-svn: 79830
|
|
|
|
|
|
| |
This also updates dominator related stuff.
llvm-svn: 79825
|
|
|
|
|
|
|
|
|
|
| |
isSafeToSpeculativelyExecute. The new method is a bit closer to what
the callers actually care about in that it rejects more things callers
don't want. It also adds more precise handling for integer
division, and unifies code for analyzing the legality of a speculative
load.
llvm-svn: 76150
|
|
|
|
|
|
|
| |
isLCSSAForm(), to test whether a loop is in the form guaranteed
by the LoopSimplify pass.
llvm-svn: 76077
|
|
|
|
|
|
| |
and use this to simplify more code.
llvm-svn: 75722
|
|
|
|
|
|
|
|
|
|
|
| |
works similar to isLoopInvariant, except that it will do trivial
hoisting to try to make the value loop invariant if it isn't already.
This makes it easier for transformation passes to clear trivial
instructions out of the way (the regular LICM pass doesn't run
until relatively late). This is code factored out of LoopSimplify
and other places.
llvm-svn: 75578
|