summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2013-07-24 12:12:17 +0000
committerChandler Carruth <chandlerc@gmail.com>2013-07-24 12:12:17 +0000
commit58e25d390542978c93ce425410eec0278a401624 (patch)
tree338a1dc68cd38efcdb02421fe3c7051e9eb2f914 /llvm/lib/Transforms/Scalar
parent8cfb43f73b23715c6acc14b13178c3f9a4b9edab (diff)
downloadbcm5719-llvm-58e25d390542978c93ce425410eec0278a401624.tar.gz
bcm5719-llvm-58e25d390542978c93ce425410eec0278a401624.zip
Fix a problem I introduced in r187029 where we would over-eagerly
schedule an alloca for another iteration in SROA. This only showed up with a mixture of promotable and unpromotable selects and phis. Added a test case for this. llvm-svn: 187031
Diffstat (limited to 'llvm/lib/Transforms/Scalar')
-rw-r--r--llvm/lib/Transforms/Scalar/SROA.cpp12
1 files changed, 9 insertions, 3 deletions
diff --git a/llvm/lib/Transforms/Scalar/SROA.cpp b/llvm/lib/Transforms/Scalar/SROA.cpp
index 860c90f3566..9ec39d25281 100644
--- a/llvm/lib/Transforms/Scalar/SROA.cpp
+++ b/llvm/lib/Transforms/Scalar/SROA.cpp
@@ -2576,7 +2576,6 @@ private:
// occurs.
if (isSafePHIToSpeculate(PN, &DL)) {
Pass.SpeculatablePHIs.insert(&PN);
- Pass.Worklist.insert(&NewAI);
IsUsedByRewrittenSpeculatableInstructions = true;
return true;
}
@@ -2606,7 +2605,6 @@ private:
// speculation occurs.
if (isSafeSelectToSpeculate(SI, &DL)) {
Pass.SpeculatableSelects.insert(&SI);
- Pass.Worklist.insert(&NewAI);
IsUsedByRewrittenSpeculatableInstructions = true;
return true;
}
@@ -3090,10 +3088,18 @@ bool SROA::rewritePartition(AllocaInst &AI, AllocaSlices &S,
if (Promotable && !Rewriter.isUsedByRewrittenSpeculatableInstructions()) {
DEBUG(dbgs() << " and queuing for promotion\n");
PromotableAllocas.push_back(NewAI);
- } else if (NewAI != &AI) {
+ } else if (NewAI != &AI ||
+ (Promotable &&
+ Rewriter.isUsedByRewrittenSpeculatableInstructions())) {
// If we can't promote the alloca, iterate on it to check for new
// refinements exposed by splitting the current alloca. Don't iterate on an
// alloca which didn't actually change and didn't get promoted.
+ //
+ // Alternatively, if we could promote the alloca but have speculatable
+ // instructions then we will speculate them after finishing our processing
+ // of the original alloca. Mark the new one for re-visiting in the next
+ // iteration so the speculated operations can be rewritten.
+ //
// FIXME: We should actually track whether the rewriter changed anything.
Worklist.insert(NewAI);
}
OpenPOWER on IntegriCloud