<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 22, 2017 at 9:25 AM, Daniel Neilson via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</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">dneilson added a comment.<br>
<span class="gmail-"><br>
In <a href="https://reviews.llvm.org/D38097#878856" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D38097#878856</a>, @dberlin wrote:<br>
<br>
> So, TL;DR, i'm not sure how much you really care, this isn't going to make your ordering completely consistent in the face of use list reordering or instruction ordering. It should work if there is a single cycle, but not if there are nested cycles.<br>
><br>
> Is there a reason not to use a complete solution, which would be "form sccs of ssa graph, sort them if necessary, perform whatever filtering you want".<br>
><br>
> Forming scc's guarantees you have all instructions that you could ever want to process.<br>
>  You can then sort the SCC's by dominance order (DT dfs numbers, then local dfs numbers) if you don't like the ordering it produces, and process.<br>
><br>
> That will guarantee completely consistent ordering, as tarjan scc's are maximal.<br>
><br>
</span>> (This will have the same time bound as the current DFS based solution)<br>
<br>
<br>
No reason other than "didn't think of it" -- my first stab at this is trying to retain as much of the existing code/behaviour as possible.<br>
<br>
Can you point me to another pass that uses the technique that you suggest? I'd like to see a sample of how it's implemented & how it works.<br></blockquote><div><br></div><div><br></div><div>There are passes that build scc's using the iterator (we have an scc_iterator) and passes that build scc's on their own (newgvn does this) for various reasons.</div><div>None of them depend on ordering to the degree that they need to sort the sccs.</div><div><br></div><div>However, GCC has a pass that works like this this (tree-ssa-sccvn.c).</div><div>It does the DFS to generate SCC's, then sorts the SCCs by RPO number and processes them as it goes.</div><div><br></div><div>This is based on this algorithm:</div><div><a href="http://softlib.rice.edu/pub/CRPC-TRs/reports/CRPC-TR95636-S.pdf">http://softlib.rice.edu/pub/CRPC-TRs/reports/CRPC-TR95636-S.pdf</a><br></div><div>(The thesis has real code: <a href="https://www.clear.rice.edu/comp512/Lectures/Papers/SimpsonThesis.pdf">https://www.clear.rice.edu/comp512/Lectures/Papers/SimpsonThesis.pdf</a>)<br><br></div><div>Which also proves processing SCC's in topo order, and then iterating the SCC  is enough to get a maximal and complete answer (you don't care about iteration).</div><div><br></div><div>For your pass, you probably want to just borrow a variant of the tarjanscc class (or share it) from NewGVN.  Just call TarjanSCC.start on each thing you are currently using as a dfs root.</div><div><br></div><div>You could either build all the components at once, or you can process as you find components.</div><div><br></div><div>If you want to process as you go, you want to process the scc right after the loop that says "Pop a component off the stack and label it".</div><div>Note that tarjan's algorithm is guaranteed to find SCC's in *reverse* topo order.  That is, no component will be found before it's successors in the condesation graph.</div><div><br></div><div>IE<br><br></div><div>Given a graph that condenses like this:</div><div>SCC A</div><div>   |</div><div>SCC B</div><div>  |</div><div>SCC C</div><div><br></div><div>It is guaranteed to find them in "C, B, A" order.</div><div><br></div><div>If you have a need to process them in topo order,  you'd have to build all the components and process the array of components in reverse order.</div><div> </div><div>--Dan</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>