[PATCH] D38097: [IVUsers] Changes to make IVUsers's results robust to instruction and uselist ordering

[Daniel Berlin via llvm-commits]

On Fri, Sep 22, 2017 at 9:25 AM, Daniel Neilson via Phabricator <
reviews at reviews.llvm.org> wrote:

> dneilson added a comment.
>
> In https://reviews.llvm.org/D38097#878856, @dberlin wrote:
>
> > 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.
> >
> > 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".
> >
> > Forming scc's guarantees you have all instructions that you could ever
> want to process.
> >  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.
> >
> > That will guarantee completely consistent ordering, as tarjan scc's are
> maximal.
> >
> > (This will have the same time bound as the current DFS based solution)
>
>
> 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.
>
> 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.
>


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.
None of them depend on ordering to the degree that they need to sort the
sccs.

However, GCC has a pass that works like this this (tree-ssa-sccvn.c).
It does the DFS to generate SCC's, then sorts the SCCs by RPO number and
processes them as it goes.

This is based on this algorithm:
http://softlib.rice.edu/pub/CRPC-TRs/reports/CRPC-TR95636-S.pdf
(The thesis has real code:
https://www.clear.rice.edu/comp512/Lectures/Papers/SimpsonThesis.pdf)

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).

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.

You could either build all the components at once, or you can process as
you find components.

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".
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.

IE

Given a graph that condenses like this:
SCC A
   |
SCC B
  |
SCC C

It is guaranteed to find them in "C, B, A" order.

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.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170923/abb147ae/attachment.html>