<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 10:06 AM, Michael Zolotukhin <span dir="ltr"><<a href="mailto:mzolotukhin@apple.com" target="_blank">mzolotukhin@apple.com</a>></span> wrote:<br><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">Hi,<div><br></div><div>My apologies, “to be fixed” is indeed a bad wording.</div><div><br></div><div>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><br></div><div>No you won't, at least, not if we preserve DT the way this has been implemented.</div><div>Like I said, i believe you've misunderstood.</div><div>If you make every pass preserve DT in this same way, it will just be slower.</div><div><br></div><div>The preservation system is an inter-pass preservation system, not an intra-pass one.</div><div><br></div><div>That is, the recomputation is happening *once* between each pass.</div><div><br></div><div><div>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><br></div><div>The way this is being updated is not *once*, but *as we go*. </div><div>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><br></div><div>*each* of those as-you go updates is saving a call to DT->recalculate that would otherwise exist.</div><div><br></div><div>So it's equivalent to adding a *ton* of DT->recalculate calls, and then making them faster by doing incremental updates.</div><div><br></div><div>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><br></div><div><br></div><div><br></div><div> <br></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"><div> 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><br></div><div>That's not why this is slow :)</div><div><br></div><div>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>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><br></div><div><br></div></div></div></div>