| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
dominator information even though dominators were previously computed.
Patch by Nick Sumner.
llvm-svn: 138449
|
|
|
|
|
|
| |
then don't split it a second time, since that block will be dead.
llvm-svn: 138153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SplitLandingPadPredecessors is similar to SplitBlockPredecessors in that it
splits the current block and attaches a set of predecessors to the new basic
block. However, it differs from SplitBlockPredecessors in that it's specifically
designed to handle landing pad blocks.
Two new basic blocks are created: one that is has the vector of predecessors as
its predecessors and one that has the remaining predecessors as its
predecessors. Those two new blocks then receive a cloned copy of the landingpad
instruction from the original block. The landingpad instructions are joined in a
PHI, etc. Like SplitBlockPredecessors, it updates the LLVM IR, AliasAnalysis,
DominatorTree, DominanceFrontier, LoopInfo, and LCCSA analyses.
llvm-svn: 138014
|
|
|
|
|
|
| |
function.
llvm-svn: 137979
|
|
|
|
| |
llvm-svn: 137978
|
|
|
|
| |
llvm-svn: 137959
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 137926
|
|
|
|
| |
llvm-svn: 137872
|
|
|
|
|
|
| |
-Wshorten-64-to-32 warning in Instructions.h.
llvm-svn: 133708
|
|
|
|
|
|
|
|
|
| |
"Reinstate r133435 and r133449 (reverted in r133499) now that the clang
self-hosted build failure has been fixed (r133512)."
Due to some additional warnings.
llvm-svn: 133700
|
|
|
|
|
|
| |
self-hosted build failure has been fixed (r133512).
llvm-svn: 133513
|
|
|
|
| |
llvm-svn: 133499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.
Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".
Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)
llvm-svn: 133435
|
|
|
|
|
|
| |
Instead, just use whatever location info first non-phi instruction has.
llvm-svn: 130729
|
|
|
|
| |
llvm-svn: 130551
|
|
|
|
|
|
| |
PHINode::Create() giving the (known or expected) number of operands.
llvm-svn: 128537
|
|
|
|
| |
llvm-svn: 128535
|
|
|
|
| |
llvm-svn: 124526
|
|
|
|
| |
llvm-svn: 124522
|
|
|
|
|
|
| |
unconditional predecessor to enable TCE on demand.
llvm-svn: 124518
|
|
|
|
|
|
| |
dominance and post-dominance frontiers.
llvm-svn: 123725
|
|
|
|
|
|
|
|
|
| |
DT->changeImmediateDominator() trivially ignores identity updates, so there is
really no need for the uniqueing provided by SmallPtrSet.
I expect this to fix PR8954.
llvm-svn: 123286
|
|
|
|
|
|
| |
is floating around in the ether.
llvm-svn: 123223
|
|
|
|
|
|
|
|
|
|
| |
phi nodes. It is called from MergeBlockIntoPredecessor which is
called from GVN, which claims to preserve these.
I'm skeptical that this is the actual problem behind PR8954, but
this is a stab in the right direction.
llvm-svn: 123222
|
|
|
|
|
|
| |
loop info.
llvm-svn: 123074
|
|
|
|
| |
llvm-svn: 123071
|
|
|
|
|
|
| |
so that Dominators.h is *just* domtree. Also prune #includes a bit.
llvm-svn: 122714
|
|
|
|
| |
llvm-svn: 121753
|
|
|
|
| |
llvm-svn: 113647
|
|
|
|
| |
llvm-svn: 111348
|
|
|
|
|
|
| |
what it does manually.
llvm-svn: 111248
|
|
|
|
|
|
|
| |
lib/Transforms/Utils and into lib/Analysis so that Analysis passes
can use them.
llvm-svn: 104949
|
|
|
|
| |
llvm-svn: 100467
|
|
|
|
| |
llvm-svn: 96387
|
|
|
|
|
|
| |
terminator's list of successors.
llvm-svn: 96377
|
|
|
|
| |
llvm-svn: 94114
|
|
|
|
|
|
|
| |
RecursivelyDeleteDeadPHINode, and DeleteDeadPHIs return a flag
indicating whether they made any changes.
llvm-svn: 92732
|
|
|
|
|
|
| |
dereference the type pointer.
llvm-svn: 92726
|
|
|
|
|
|
|
|
|
|
| |
Intrinsic::dbg_stoppoint
Intrinsic::dbg_region_start
Intrinsic::dbg_region_end
Intrinsic::dbg_func_start
AutoUpgrade simply ignores these intrinsics now.
llvm-svn: 92557
|
|
|
|
| |
llvm-svn: 90836
|
|
|
|
|
|
|
|
|
|
|
|
| |
makes several optimization passes abort in cases where they're currently
silently miscompiling code.
Remove the indirectbr assertion from SplitEdge. Indirectbr is only
a problem for critical edges, and SplitEdge defers to SplitCriticalEdge
to handle those, and SplitCriticalEdge has its own assertion for
indirectbr.
llvm-svn: 86147
|
|
|
|
|
|
|
|
|
| |
when BB2 has its address taken. Since it ends up doing BB2->rauw(BB1),
this can cause the address of the entry block to be taken. Since it is
generally undesirable to nuke blocks whose address is taken, even when
we can, just unconditionally stop this xform.
llvm-svn: 85708
|
|
|
|
|
|
| |
Fix CodeGenPrepare to not try to split edges from indirectbr.
llvm-svn: 85690
|
|
|
|
|
|
|
| |
auto-update the DominatorTree because it doesn't keep the DominatorTree
current while it works.
llvm-svn: 85670
|
|
|
|
| |
llvm-svn: 85668
|
|
|
|
|
|
|
| |
MergeBlockIntoPredecessor. This makes SimplifyCFG slightly more aggressive,
and makes it unnecessary for LoopUnroll to have its own copy of this code.
llvm-svn: 85667
|
|
|
|
| |
llvm-svn: 85327
|
|
|
|
|
|
|
|
| |
where a loop's header is being split and it has predecessors which are not
contained by the most-nested loop which contains the loop.
This fixes PR5235.
llvm-svn: 84505
|
|
|
|
|
|
| |
update all the callers.
llvm-svn: 82889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|