[PATCH] D16637: [SimplifyCFG] limit recursion depth when speculating instructions (PR26308)

[Daniel Berlin via llvm-commits]

If you do it on literally every two entry phi nodes, why is the answer not:

Number each node of dominator tree with depth in dom tree (IE level).
Process dominator tree in level order, visiting all nodes of a given level
before the next deeper level:
  Try to speculate a given phi node.
  Stop anytime you hit a phi node with a level above you above you (because
you will have already speculated it if you could).
  Track visited phi nodes to avoid cycles.


Or something similar.
Over time, we seem to expand a lot of lazy-walking optimizations to do
these "walk possibly everything backwards" types of algorithms, and at the
point we want to walk *everything of a certain type* there is no point in
doing it lazily.


On Wed, Jan 27, 2016 at 10:32 AM, David Majnemer <david.majnemer at gmail.com>
wrote:

> majnemer added a comment.
>
> In http://reviews.llvm.org/D16637#337461, @dberlin wrote:
>
> > Errr, rather than limit recursion depth, why not just keep track of
> what's
> >  visited and avoid the cycles?
> >
> > (You could also cheaply build sccs of the instruction and it's uses, and
> >  decide what to do for each SCC as a whole, which would avoid this issue
> as
> >  well)
>
>
> We run DominatesMergePoint on every two entry phi node.  Using a set of
> visited blocks would still be pretty expensive because, in the worst case,
> DominatesMergePoint might recurse back to the entry node if there are a lot
> of cheap BBs.  I think it would make sense to have a depth limit to handle
> such pathological cases.
>
>
> http://reviews.llvm.org/D16637
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160127/02814565/attachment.html>