<div dir="ltr">How about some stats about the number of eraseBB calls from JumpThreading?<div><br></div><div>An alternative way of fixing the problem which requires slight change in interface -- the erase interface need to pass in number of successors of the 'BB' before it is erased. in BPI, you can form the 'Edge' keys from 'BB' and index and erase them.</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 20, 2016 at 9:51 AM, Igor Laevsky <span dir="ltr"><<a href="mailto:igor@azulsystems.com" target="_blank">igor@azulsystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">igor-laevsky added a comment.<br>
<br>
Hi,<br>
<br>
I don't have specific build times. This is mostly motivated by the review comments in the <a href="https://reviews.llvm.org/D20957" rel="noreferrer" target="_blank">https://reviews.llvm.org/D20957</a>. Evidence for importance of this is that LVI also had linear time EraseBlock and it caused problems there. BPI will call EraseBlock exactly as frequently as LVI did, so it's natural to assume that performance bottleneck will be in the same place.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D22414" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22414</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>