<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 6:56 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: <a href="https://llvm.org/bugs/show_bug.cgi?id=28400" target="_blank">https://llvm.org/<wbr>bugs/show_bug.cgi?id=28400</a><div><br></div><div>Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this:</div><div><br></div><div>1. LVI holds an AssertingVH pointing at a BasicBlock</div><div>2. Some other pass ends up deleting that BB (e.g. SimplifyCFG)</div><div>3. BOOM</div><div><br></div><div>Notice that this ends up happening even though SimplifyCFG ultimately invalidates LVI. But that only happens after the AssertingVH has been triggered.</div><div><br></div><div>We would avoid this issue in principle by just switching those AssertingVH to observing pointers, but then we would have dangling pointers. I'm pretty sure that any analysis that keeps pointers to IR is in fact ending up with dangling pointers like this.</div><div><br></div><div>I've noticed that AssumptionCache using CallbackVH that allow it to update its data structures correctly in this case.</div><div><br></div><div>Just using regular pointers will end up with dangling pointers in this scenario. This isn't a problem in practice since the analysis will hopefully be invalidated and stop holding the dangling pointers, but it just seems weird. Thankfully, ASan can generally catch problems if we do try to access through any of these dangling pointers.</div><div><br></div><div>Thoughts? For the moment I have put in a workaround (r274457) that makes jump-threading invalidate LVI.</div></div></blockquote><div><br></div><div>Is everybody happy with this workaround? Although I mentioned it a couple times in this thread nobody seems to have explicitly commented on it.</div><div><br></div><div>This issue does manifest in almost any non-trivial pipeline containing affected analyses (analyses that use AssertingVH to reference pieces of IR; in particular, LazyValueInfo, ScalarEvolution, and CallGraph) and this workaround seems simple enough for the moment.<br></div><div><br></div><div>One caveat I ran into is that if you ever manually `require<scalar-evolution>` (as you would before entering a loop pass manager with a loop pass that needs ScalarEvolution), you need to remember to `invalidate<scalar-evolution>` after running the loop passes to make sure it gets invalidated.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span></div>
</blockquote></div><br></div></div>