summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ScalarEvolutionNormalization.cpp
diff options
context:
space:
mode:
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>2015-10-10 00:53:03 +0000
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>2015-10-10 00:53:03 +0000
commit5a82c916b0df6312a9192d0e8d7428ea6793384d (patch)
tree8960d4f82fcae9d24f24f6f25d75b98003220762 /llvm/lib/Analysis/ScalarEvolutionNormalization.cpp
parent72cf83d03b03b19122d674baed433b46621f58d1 (diff)
downloadbcm5719-llvm-5a82c916b0df6312a9192d0e8d7428ea6793384d.tar.gz
bcm5719-llvm-5a82c916b0df6312a9192d0e8d7428ea6793384d.zip
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis. I came across something really scary in `llvm::isKnownNotFullPoison()` which relied on `Instruction::getNextNode()` being completely broken (not surprising, but scary nevertheless). This function is documented (and coded to) return `nullptr` when it gets to the sentinel, but with an `ilist_half_node` as a sentinel, the sentinel check looks into some other memory and we don't recognize we've hit the end. Rooting out these scary cases is the reason I'm removing the implicit conversions before doing anything else with `ilist`; I'm not at all surprised that clients rely on badness. I found another scary case -- this time, not relying on badness, just bad (but I guess getting lucky so far) -- in `ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the insertion point, do some things, and then restore it. Previously, we let the iterator auto-convert to `Instruction*`, and then set it back using the `Instruction*` version: Instruction *PrevInsertPoint = Builder.GetInsertPoint(); /* Logic that may change insert point */ if (PrevInsertPoint) Builder.SetInsertPoint(PrevInsertPoint); The check for `PrevInsertPoint` doesn't protect correctly against bad accesses. If the insertion point has been set to the end of a basic block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns an iterator pointing at the list sentinel. The version of `SetInsertPoint()` that's getting called will then call `PrevInsertPoint->getParent()`, which explodes horribly. The only reason this hasn't blown up is that it's fairly unlikely the builder is adding to the end of the block; usually, we're adding instructions somewhere before the terminator. llvm-svn: 249925
Diffstat (limited to 'llvm/lib/Analysis/ScalarEvolutionNormalization.cpp')
-rw-r--r--llvm/lib/Analysis/ScalarEvolutionNormalization.cpp2
1 files changed, 1 insertions, 1 deletions
diff --git a/llvm/lib/Analysis/ScalarEvolutionNormalization.cpp b/llvm/lib/Analysis/ScalarEvolutionNormalization.cpp
index b238fe43cc6..b7fd5d50617 100644
--- a/llvm/lib/Analysis/ScalarEvolutionNormalization.cpp
+++ b/llvm/lib/Analysis/ScalarEvolutionNormalization.cpp
@@ -109,7 +109,7 @@ TransformImpl(const SCEV *S, Instruction *User, Value *OperandValToReplace) {
SmallVector<const SCEV *, 8> Operands;
const Loop *L = AR->getLoop();
// The addrec conceptually uses its operands at loop entry.
- Instruction *LUser = L->getHeader()->begin();
+ Instruction *LUser = &L->getHeader()->front();
// Transform each operand.
for (SCEVNAryExpr::op_iterator I = AR->op_begin(), E = AR->op_end();
I != E; ++I) {
OpenPOWER on IntegriCloud