search for: hoistivinc

...d instruction re-use by picking a more canonical insertion position in the case where a new insert position block is not found. The problem I have run into with this change is that it causes an insert position instruction to be chosen which is later hoisted into a different block by SCEVExpander::hoistIVInc(). This in turn makes the SCEVExpander Builder InsertPt inconsistent (the instruction and block end up not matching), which leads to an invalid instruction being inserted (with its parent != its containing block). Does anyone more familiar with the design of the LSR/SCEV interaction have an op...

...picking a more canonical insertion > position in the case where a new insert position block is not found. > > The problem I have run into with this change is that it causes an insert > position instruction to be chosen which is later hoisted into a different > block by SCEVExpander::hoistIVInc(). This in turn makes the SCEVExpander When is the insert position moved? IOW, what is the "timeline" of events? There are two calls to hoistIVInc in SCEVExpander, in getAddRecExprPHILiterally and in replaceCongruentIVs -- which one is the problematic case? > Builder InsertPt inco...

...ciently 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 asserts that the basic block we're inserting into is the same as the insertee's parent. -- Sanjoy

...struction re-use by picking a more canonical insertion position in the case where a new insert position block is not found. > The problem I have run into with this change is that it causes an insert position instruction to be chosen which is later hoisted into a different block by SCEVExpander::hoistIVInc(). This in turn makes the SCEVExpander Builder InsertPt inconsistent (the instruction and block end up not matching), which leads to an invalid instruction being inserted (with its parent != its containing block). > > Does anyone more familiar with the design of the LSR/SCEV interaction ha...