<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 8:31 AM, Jakub (Kuba) Kuderski <span dir="ltr"><<a href="mailto:kubakuderski@gmail.com" target="_blank">kubakuderski@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"><div>Hi Brian,</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:12.8px"> I was thinking about this over the weekend and I was thinking of a new class named DeferredDeviceTree or DeviceTreeDeferred. It would have the following methods:</div><div style="font-size:12.8px">deleteEdge()</div><div style="font-size:12.8px">insertEdge()</div><div style="font-size:12.8px">appyUpdates(Updates)</div><div style="font-size:12.8px">sync()</div></blockquote><div><br></div></span><div>s/Device/Dominator? :P<br><br>My first observation would be that we don't really need deleteEdge and insertEdge, as the applyUpdates can now perform a non-batching update when there is only one qnqueued -- I think that applyUpdates is enough, end with initializer list passed is not that verbose (Sth.applyUpdates({DT::Insert, BB_A, BB_B}). Instead, it would be nice to have some automatic way of handling current IR API like replaceAllUsesWith that is cumbersome with the current CFG-level update logic.<br><br>Then, I think that it might be also possible to deffer updates until someone calls DT.dominates(...) or similar function that need DT to be updated,</div></div></blockquote><div><br></div><div>You'd have to do it when getNode, dominates, children, etc, pretty much every method.</div><div> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>so maybe it would make sense to make the interface lazy all the way and not expose the synchronization at all? </div></div></blockquote><div><br></div><div>If you think we can pull it off, ...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Or only provide synchronization for debugging.<br>The problem I see with this approach is that it would not immediately obvious how to be smart enough not to store invalid pointers to already deleted basic blocks. </div></div></blockquote><div><br></div><div>I don't see why a combination of two things wouldn't work:<br>1. WeakVH to the BasicBlock. BasicBlock's are Value, so this will invalidate properly and become nullptr.</div><div>2. Since, for the deleted blocks, you are mainly looking for the DT node they referred to, store that at applyUpdates time.</div><div><br></div></div></div></div>