[PATCH] D24805: [GVNSink] Initial GVNSink prototype

[Sebastian Pop via llvm-commits]

sebpop added a comment.

Hi James,

after I discussed with @hiraditya, we realized that the example you give
is not supposed to be sinked by a GVN-sink pass:

  [ %a1 = add i32 %b, 1  ]   [ %c1 = add i32 %d, 1  ]
  [ %a2 = xor i32 %a1, 1 ]   [ %c2 = xor i32 %c1, 1 ]
                 \           /
           [ %e = phi i32 %a2, %c2 ]
           [ add i32 %e, 4         ]

Sinking this example would need the bisimulation algorithm implemented in simplifyCFG:
that part is the one using the LockstepReverseIterator.  I think there is value to separate
that algorithm from simplifyCFG to be able to run it separately from the CFG transforms.
Let's submit a patch that outlines all the functions dealing with sinking in simplifyCFG
in a separate code sinking pass.  That pass should be able to catch the example you gave.

A GVN-sink pass will not catch the above example and it will sink other
cases that the bisimulation algorithm will not be able to catch: those are all the
expressions for which GVN will return the same number.  For example:

  [ store 1, %gep1 ]    [ store 1, %gep2 ]
             \             /
            [     ...        ]

if GVN decides that %gep1 and %gep2 are actually the computation of
the same memory address, and there are no side effects on the path
from the stores to the next BB, then we should be able to sink the two stores.

I think the two algorithms are complementing each other: I don't expect
GVN-sink to handle all the cases and I think we should keep both transforms
in two separate passes.


Repository:
  rL LLVM

https://reviews.llvm.org/D24805