<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">I *believe* the motivation is that they want DT up to date *in-pass* so they can use it do to better jump threading over loops.</span></blockquote><div><span style="font-size:12.8px">Daniel, you are correct in this assumption. Dominance is the first step in enhancing the kinds of analysis and extend the number of Jumpthreading opportunities. Analysis of loops is part of this work.</span></div><div><span style="font-size:12.8px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">*that* kind of change, IMHO, should be subject to our usual "how much faster code does it make vs how much does it cost" tradeoff.</span></blockquote><div>I have not started the work on actual code optimizations simply because I could not intelligently make the analysis decisions needed. Rather than create a huge change to JT (or another pass) Sebastian and I decided to incrementally update JT with the features we needed to get us to the end goal.</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"><span style="font-size:12.8px">This was *our* plan to remove the recalculates, but it does not appear to have be what Sebastian/etc want for JT.</span></blockquote><div>I'm a bit confused by this statement: that's what the patch is doing. There's only one corner-case where a recalculate occurs. The rest of the time it's incremental updates.  There may still be opportunities to batch updates but I honestly have no idea if it will be more efficient. If this is a concern I can talk to Sebastian when he returns to work on Monday about re-working the patch for batching.  Or we could talk about it in person at the LLVM conference next week. :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 12:39 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Oct 13, 2017 at 10:35 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Oct 13, 2017, at 10:17 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div><br class="m_-8047120780017687167m_-1538319548817559119Apple-interchange-newline"><div><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></div></div></div></blockquote></span>Hmm, maybe I indeed misunderstood. What is the motivation for this change then?</div></div></blockquote><div><br></div></span><div>So, this is actually why i went looking, because i had trouble believing it was 4-10% slower (I've done a lot of testing of random cfgs :P)</div><div><br></div><div>I *believe* the motivation is that they want DT up to date *in-pass* so they can use it do to better jump threading over loops.</div><div><br></div><div>*that* kind of change, IMHO, should be subject to our usual "how much faster code does it make vs how much does it cost" tradeoff.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> 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></blockquote><div><br></div></span><div>This was *our* plan to remove the recalculates, but it does not appear to have be what Sebastian/etc want for JT.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="m_-8047120780017687167HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="m_-8047120780017687167HOEnZb"><font color="#888888">Michael</font></span><span><br></span></div></div></blockquote></div><br></div></div>
</blockquote></div><br></div>