<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 1, 2016 at 1:36 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</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"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Perhaps i am missing something, however.  I will stare at the patch.</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>Looks like what complicates the matter is that the SCC formation is done on the fly while the graph is traversed/iterated (lazily formed).</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>This is standard, tarjan's algorithm works just fine in that case.</div></div></div></div></blockquote><div><br></div></span><div>yes -- my point is that with your algorithm, the non-ref sccs will need to be formed eagerly first and then forming refSCCs can be done in a lazy fashion.</div></div></div></div></blockquote><div><br></div><div>Yes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>all.  Looking at the example in Figure 2. Reverse top-order of the callgraph is first formed. The SCC pass manager processes 'j', and then node 'v'. After processing 'v', a new call edge is discovered to node 'w', incremental update is applied, and 'v' 's analysis result is invalidated and will be processed later. The pass manager will then process 'h', 'i', 'f'</div><span><div><br></div></span></div></div></div></blockquote><div><br></div></span><div>Be careful, all of these algorithms are N^2.</div><div><br></div></div></div></div></blockquote><div><br></div><div><br></div></span><div>For sparse graph (which CG usually is), the soft threshold search algorithm to maintain SCC has complexity of O(m^3/2) where m is the number of new arcs added -- so it does not look too bad :)</div></div></div></div></blockquote><div><br></div><div>....</div><div><br></div><div>So, it's been a few years, and we didn't try this algorithm (we tried pearce's), but when i tried algorithms to dynamically maintain SCC's and topo order as part of an andersen's solver, they were slower than just redoing the ordering/scc finding on each pass :)<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">So i'd play with them to see how well they work in practice.</div><div class="gmail_quote"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>David </div></font></span></div><br></div></div>
</blockquote></div><br></div></div>