[PATCH] D24805: [GVNSink] Initial GVNSink prototype

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

In https://reviews.llvm.org/D24805#760949, @jmolloy wrote:

> Hi Danny,
>
> Thanks for making me think more about the iteration order. Regardless of the difficulties of forming inverse RPO, I now think I was completely wrong about the preferred iteration order.


I don't believe you are.

Most sinking passes operate in IRPO or PDT order.

> For a sinking pass, surely a *forward* walk (preds before succs) is more optimal than a backward walk.

Nope.

For most sinking passes, the blocker is the thing below the current instructions

> Pushing instructions down the graph exposes more opportunities for sinking later on.

Yes, which is why things operate in reverse-local, succs before preds order.

given

  A:
  store 1
  B:
  store 2
  C
  store 3

They want to do "sink store 3, sink store 2, sink store 1".

This is IRPO order, walking each basic block backwards.

If you do sink store 1, sink store 2, sink store 3, you may only be able to sink store 1 to store 2's location, and store 2 to store 3's location.
Then once you move store 3, you must repeat.

The above may take 3 iterations to be optimal in a forward RPO pass
It takes 1 in a IRPO pass.

> So I think a single pass, RPO walk of the CFG is sufficient (and indeed passes all my testcases and all the internal testing I can throw at it).

This is pretty surprising.

Given two must-aliased stores, for example, i can't see how this would sink them as far as possible in one iteration.


Repository:
  rL LLVM

https://reviews.llvm.org/D24805