[PATCH] D24805: [GVNSink] Initial GVNSink prototype

[Daniel Berlin via llvm-commits]

On Mon, May 22, 2017 at 8:41 AM, James Molloy <James.Molloy at arm.com> wrote:

> Hi,
>
> Thanks for the quick reply; this is a very helpful and constructive
> discussion :)
>

Happy to help :)


>
> The oversimplification and repetition below is for my own understanding
> and so that I can better understand your replies, as you know this subject
> far better than I.
>
> A: store 1
> B: store 2
> C: store 3
> D:
>
> I understand that in a classical sinking algorithm we'd want to walk
> backwards:
>   1) Sink 'store 3' from C to D
>   2) Sink 'store 2' from B to D
>   3) Sink 'store 1' from A to D
>
> A key to this working is that each instruction, when considered, was sunk
> as far as it could be. If we had added the restriction that an instruction
> could only be sunk to its immediate successor block, that algorithm would
> have taken three iterations to reach a fixpoint.
>
Yes


>
> GVNSink can (at the moment at least) only sink instructions from a block
> into its immediate successor. This is what allows it to model accurately
> enough how many PHIs it is going to create and whether sinking is actually
> worthwhile (and how much sinking)


How much is the former, and how much is the later?

The number of phis you can create is calculable ahead of time in O(N) time
for all operands, and related the availability of values
(in particular, you will create a phi for any value with two different
leaders at a join point you must pass to sink it. If you calculate this
properly, and in topo order of expressions, such that you process operands
before things that use them, you can calculate the number of phis you would
insert in O(N) time overall)


. I don't believe it would be able to handle all the cases it currently
> does if it didn't have this restriction (but would be able to handle other
> cases that it currently can't, so I see that very much as an enhancement
> I'd like to add later).
>

I actually don't buy this, fwiw.
It's entirely possible to calculate all the hypothetical insertion points
ahead of time, and figure out which make sense from a cost perspective.
There are sinking (and PRE) algorithms that do this.
You could do exactly the same cases you do now.


Now, whether you want that complexity is a different question :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170522/9d20d6d3/attachment.html>