<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><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: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><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><br></div><div> </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=""><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>In order to ensure the visit order, the RefSCCs are formed first.</div></div></div></div></blockquote><div><br></div></span><div>In the algorithm above, the ref-scc's should also be output in topo-order, because we only visit successor ref-scc's after we've formed a given ref-scc.</div><div><br>You just have to track the relative orders.</div><div><br></div><div>Note that you can even do it multi-core in quasi-linear time and get serious speedups.<br><a href="http://conf.researchr.org/home/PPoPP-2016" target="_blank">http://conf.researchr.org/home/PPoPP-2016</a><br></div><div><br></div><div>(search for "Multi-core on-the-fly SCC decomposition". the conference is open access, so you will have access to the paper, but if i direct link it, it don't work)</div><span class=""><div><br></div><div><br></div><div><br></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"><span><div><br></div></span><div>Thanks for the reference! I have not read it in details, but just browsing through the algorithm, if it is employed to do dynamic cycle update and node reordering -- there does not seem to be need for Ref edges and Ref SCC at 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><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><br></div><div>David </div></div><br></div></div>