search for: restoreip

...invariant to have. I don't see why (2) would be particularly ugly though (perhaps I'm not being sufficiently imaginative :) ). I think IRBuilder::SetInsertPoint(Instruction *) is safe, since it always sets BB and IP in sync with each other. So I think we basically need to sync things at restoreIP() (which is called only once in the file) and at places that potentially move insertion points (like hoistIVInc) using something like "Builder.SetInsertPoint(&*Builder.GetInsertPoint())". Are there any other places that need to be fixed too? We should also add a LSRInserter that ass...

...nd printing the guard again. 195 public: 196 InsertPointGuard(IRBuilderBase &B) 197 : Builder(B), Block(B.GetInsertBlock()), Point(B.GetInsertPoint()), -> 198 DbgLoc(B.getCurrentDebugLocation()) {} 199 200 ~InsertPointGuard() { 201 Builder.restoreIP(InsertPoint(Block, Point)); (lldb) p *this (llvm::IRBuilderBase::InsertPointGuard) $6 = { Builder = 0x00007fff5fbf4440 Block = { llvm::ValueHandleBase = { PrevPair = (Value = 4337803886) Next = 0x000000010615b0a8 V = 0x000000010615b170 } } Point = { NodePtr = 0...

Hi All, I've run into what appears to be a bug in ScalarEvolution, but I'm not sure if it is instead caused by me missing an implicit assumption between LSR and SCEV. This issue is caused by the change D18001 <http://reviews.llvm.org/D18001> , which is an attempt to increase SCEV-inserted instruction re-use by picking a more canonical insertion position in the case where a new