[PATCH] D18798: New code hoisting pass based on GVN

[Daniel Berlin via llvm-commits]

>
>
> >
> Thanks for the feedback. Yes, in the current implementation we value
> number each instruction only once. When an expression is hoisted still the
> value numbers are not invalidated because one of the expressions in the
> child branch gets hoisted.
>

Right. This is a very trivial form of hoisting using the dominator tree.


>
> So, an extension of this algorithm could be to start hoisting equivalent
> (scalar) expressions across non-sibling branches.


This will not work if the branches are ever back edges or blocks with
multiple predecessors in general unless all predecessors are part of the
same branch of the dominator tree.


> In that case, I think, we would still value number only once,

Only if the conditions above are met (that's off the top of my head, i'm
pretty sure i could think of more).





> if we hoist one of the expressions and delete the rest. For loads, or
> other expressions with side-effects, hoisting would require more
> complicated analysis across each edge dominated by the common dominator of
> the equivalent expressions, so maybe we could skip that to save compile
> time, I'm not very sure about this though.


It's actually a pretty simple analysis, FWIW:

With memory-ssa, all loads have a "def" of the nearest thing above them
that kills them.  So if the loads reach the same def, you can hoist them to
that def. If they do not, you cannot.
You can do extra work to see if you can somehow go back past that def if
you like.




> Could you give an example of a case when multiple value numbering of same
> expression will be required, that will be helpful.
>
>
Anything whose value depends on a phi node, directly or indirectly.  For
multiple predecessor blocks, if you are trying to determine constant values
of things and not just sameness, it will also take multiple iterations to
get correct answers.

See, in general, the description of the RPO algorithm in
https://www.cs.rice.edu/~keith/Promo/CRPC-TR95636.pdf.gz


Currently

> http://reviews.llvm.org/D18798
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160418/b961d525/attachment.html>