<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 Oct 13, 2017, at 10:17 AM, 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 Fri, Oct 13, 2017 at 10:06 AM, Michael Zolotukhin <span dir="ltr" class=""><<a href="mailto:mzolotukhin@apple.com" target="_blank" class="">mzolotukhin@apple.com</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"><div style="word-wrap:break-word" class="">Hi,<div class=""><br class=""></div><div class="">My apologies, “to be fixed” is indeed a bad wording.</div><div class=""><br class=""></div><div class="">I do agree that preserving DT is generally good. However, what we get from it *currently* is only slowdowns with some gains expected *in future* when other passes are taught to preserve DT as well. I believe that when all relevant passes preserve DT we’ll see compile-time improvements,</div></div></blockquote><div class=""><br class=""></div><div class="">No you won't, at least, not if we preserve DT the way this has been implemented.</div><div class="">Like I said, i believe you've misunderstood.</div><div class="">If you make every pass preserve DT in this same way, it will just be slower.</div></div></div></div></div></blockquote>Hmm, maybe I indeed misunderstood. What is the motivation for this change then? I thought we were going to replace one expensive DT->recalculate (which happens between passes when we don’t preserve DT) with several cheap incremental DT updates. Is this correct?</div><div><br class=""></div><div>Michael<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">The preservation system is an inter-pass preservation system, not an intra-pass one.</div><div class=""><br class=""></div><div class="">That is, the recomputation is happening *once* between each pass.</div><div class=""><br class=""></div><div class=""><div class="">Replacing the rebuilding that exists now would only require batching the updates and applying them once to DT at the end of jump threading (DT supports this already). That will certainly be fast enough already.</div></div><div class=""><br class=""></div><div class="">The way this is being updated is not *once*, but *as we go*. </div><div class="">Not in the incremental sense, but in the quite literal sense of "for each cfg change that is made, the DT is updated" instead of "batch a bunch of CFG updates into a DT update".</div><div class=""><br class=""></div><div class="">*each* of those as-you go updates is saving a call to DT->recalculate that would otherwise exist.</div><div class=""><br class=""></div><div class="">So it's equivalent to adding a *ton* of DT->recalculate calls, and then making them faster by doing incremental updates.</div><div class=""><br class=""></div><div class="">There is no way to make this faster than a single recomputation of DT , because it's not equivalent to that, it's equivalent to adding DT->recalculate everywhere you DT->applyUpdates in this patch.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> <br class=""></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="word-wrap:break-word" class=""><div class=""> that’s why I don’t want to lose this work and propose to put it under a flag (also to avoid bitrot). But now we’re just doing extra work for nothing - SimplifyCFG scheduled right after JT destroys DT and we have to recompute it anyway.</div></div></blockquote><div class=""><br class=""></div><div class="">That's not why this is slow :)</div><div class=""><br class=""></div><div class="">It's slow because it's equivalent to adding 50 new DT recalculations, and then trying to make them faster by doing them incrementally.</div><div class="">It would *already* be fast enough if instead it was "batch up all the updates, apply at end of jumpthreading", which would be equivalent to preserving DT the way the inter-pass system preserves it.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></body></html>