<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 13, 2017 at 10:48 AM, Brian M. Rzycki <span dir="ltr"><<a href="mailto:brzycki@gmail.com" target="_blank">brzycki@gmail.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 dir="ltr"><span class="gmail-"><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></span><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><span class="gmail-"><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></span><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><span class="gmail-"><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></span><div>I'm a bit confused by this statement: that's what the patch is doing. </div></div></blockquote><div><br></div><div>You are confused because i was talking about the recalculations that occur elsewhere.</div><div><br>But let me try to diagram it for you.</div><div><br></div><div>Here is the equivalent of what JT did before your patch<br><br></div><div><br></div><div>iterate</div><div> for each bb</div><div>    maybe change an edge and some code</div><div> call some utilities<br></div><div> for each dead block</div><div>    erase it</div><div>DT->recalculate<br></div><div><br></div><div>Here is what your patch would look like without the incremental API existing:<br>iterate</div><div>  for each bb</div><div>   maybe change an edge and some code</div><div>   for each edge we changed:</div><div>     DT->recalculate</div><div>  call some utilities, calling DT->recalculate in each one</div><div> for each dead block</div><div>    erase it</div><div>    DT->recalculate</div><div><br></div><div>You can see that this has added a O(number of changes ) DT->recalculate calls compared to what happened before.</div><div><br></div><div>That would be ridiculously slow. Probably 100x-1000x as slow as the first case.</div><div><br></div><div>You then have changed that O(number of changes) set of calls to use the incremental API, so that it looks like this:<br><div>iterate</div><div>  for each bb</div><div>   maybe change an edge and some code</div><div>   for each edge we changed:</div><div>     incremental update DT</div><div>  call some utilities, calling incremental update DT in each one</div><div> for each dead block</div><div>    erase it</div><div>    incremental update DT</div></div><div><br></div><div>These calls, unfortunately are not O(1) and will never be O(1) (doing so is provably impossible)<br></div><div>So it's not an O(N) cost you've added it, it's N^2 or N^3 in the worst case.</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 dir="ltr"><div>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. </div></div></blockquote><div><br></div><div>It will, because it will cause less updating in practice.</div><div><br></div><div>If jump threading changes edge A->B to A->C (IE insert new edge, remove old edge)  and then changes edge A->C to A->D , you will perform two updates.</div><div>If those require full recalculation of the tree (internal to the updater), you will update the tree twice.</div><div>Batching will perform one.</div><div><br></div><div><br></div><div><br></div></div></div></div>