summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/GVNSink.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Hide dbgs() stream for when built with -fmodules.Frederich Munch2017-06-141-0/+11
| | | | | | | | | | | | | | Summary: Make DebugCounter::print and dump methods to be const correct. Reviewers: aprantl Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34214 llvm-svn: 305408
* Changed a comparison operator for std::stable_sort to implement strict weak ↵Galina Kistanova2017-06-081-3/+3
| | | | | | | | | ordering. This is a temporarily fix which needs additional work, as it triggers a test3 failure. test3 is commented out till then. llvm-svn: 304993
* [GVNSink] Pacify MSVCJames Molloy2017-05-251-1/+1
| | | | | | Don't convert an unsigned to a pointer for a sentinel, use a size_t instead. llvm-svn: 303855
* [GVNSink] Don't define operator<< in NDEBUGJames Molloy2017-05-251-0/+2
| | | | | | | Without debug macros enabled, the raw_ostream operator<< overload is unused. llvm-svn: 303852
* [GVNSink] GVNSink passJames Molloy2017-05-251-0/+870
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. 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. Differential revision: https://reviews.llvm.org/D24805 llvm-svn: 303850
OpenPOWER on IntegriCloud