[PATCH] D24805: [GVNSink] Initial GVNSink prototype

James Molloy via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 21 09:02:46 PDT 2016


jmolloy created this revision.
jmolloy added reviewers: dberlin, sebpop, spop.
jmolloy added a subscriber: llvm-commits.
jmolloy set the repository for this revision to rL LLVM.
Herald added subscribers: mgorny, beanz, mehdi_amini.

This patch provides an initial prototype for a pass that sinks instructions based on GVN information, similar to GVNHoist. It is not yet ready for commiting but I've uploaded it to gather some initial thoughts.

This pass attempts to sink instructions into successors, reducing static instruction count and enabling if-conversion. We use a variant of global value numbering to decide what can be sunk. Consider:

    [ %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         ]

GVN would number %a1 and %c1 differently because they compute different results - the VN of an instruction is a function of its opcode and the transitive closure of its operands. This is the key property for hoisting and CSE.

What we want when sinking however is for a numbering that is a function of the *uses* of an instruction, which allows us to answer the question "if I replace %a1 with %c1, will it contribute in an equivalent way to all successive instructions?". The (new) PostValueTable class in GVN provides this mapping.

There is a lot of bikeshedding to be done here. Other notable things to do:
* Throw *much* more testing at it
* Remove virtual function calls in ValueTable, using CRTP
* Bikeshed PostValueTable
* Tweak the sinking heuristic
* Work out when it needs to run in the pass pipeline
* Properly update MemorySSA instead of fully invalidating it
* Run away from Danny when he sees what havoc I've wrought with GVN and MemorySSA

This pass has some shown really impressive improvements especially for codesize already on internal benchmarks, so I have high hopes it can replace all the sinking logic in SimplifyCFG.

Repository:
  rL LLVM

https://reviews.llvm.org/D24805

Files:
  include/llvm/InitializePasses.h
  include/llvm/Transforms/Scalar.h
  include/llvm/Transforms/Scalar/GVN.h
  include/llvm/Transforms/Utils/MemorySSA.h
  lib/Transforms/IPO/PassManagerBuilder.cpp
  lib/Transforms/Scalar/CMakeLists.txt
  lib/Transforms/Scalar/GVN.cpp
  lib/Transforms/Scalar/GVNSink.cpp
  lib/Transforms/Scalar/Scalar.cpp
  lib/Transforms/Utils/MemorySSA.cpp
  test/Transforms/GVNSink/sink-common-code.ll
  test/Transforms/SimplifyCFG/sink-common-code.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D24805.72065.patch
Type: text/x-patch
Size: 58074 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160921/b86f55ce/attachment-0001.bin>


More information about the llvm-commits mailing list