<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 22, 2016, at 12:20 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" class="">dberlin@dberlin.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Aug 22, 2016 at 12:07 PM, Mehdi AMINI via llvm-commits <span dir="ltr" class=""><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">mehdi_amini added inline comments.<br class="">
<br class="">
================<br class="">
Comment at: lib/Transforms/Scalar/ADCE.<wbr class="">cpp:459<br class="">
@@ -395,2 +458,3 @@<br class="">
void getAnalysisUsage(AnalysisUsage &AU) const override {<br class="">
- AU.setPreservesCFG();<br class="">
+ AU.addRequired<<wbr class="">PostDominatorTreeWrapperPass>(<wbr class="">);<br class="">
+ AU.setPreservesCFG(); // TODO -- will remove when we start removing branches<br class="">
----------------<br class="">
How expensive is this?<br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">FWIW: On very large testcases that take many many seconds, postdom usually costs <1 second.</div><div class=""><br class=""></div><div class="">The real cost is if we use it in a lot of places without an update scheme, such that it gets invalidated a lot.</div><div class=""><br class=""></div><div class="">I mentioned this privately to a few folks, but i actually have such an update scheme -</div><div class="">There are recent advances in incremental dominator tree algorithms that make it so we can update postdom under random edge addition and deletion very quickly, and in most cases, at least 50-100x faster than we can rebuild it.</div><div class="">The only thing required is to tell it what CFG edges you added/removed.</div><div class=""><br class=""></div><div class="">It's based on the algorithms in <a href="http://arxiv.org/pdf/1604.02711v1.pdf" class="">http://arxiv.org/pdf/1604.02711v1.pdf</a> (I have the code from the paper, and hacked it into llvm for testing purposes :P)</div><div class=""><br class=""></div><div class="">note: the timings here are for complete incremental update after each change. If you batch changes, it is at least an order of magnitude cheaper.</div><div class=""><br class=""></div><div class="">Insertion is very cheap, it's deletion that can be expensive.</div></div></div></div></div></blockquote></div><br class=""><div class="">Nice, I’ve been stuck with trying to use the DomTree in (I think) Jump Threading, and being unable to preserve it. I’ll look forward into this if you ever get to commit such facilities (I doubt I’ll find time to study the paper in the near future…).</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>