forked from OSchip/llvm-project
390dfde0f3
Summary: GVNHoist performs all the optimizations that MLSM does to loads, in a more general way, and in a faster time bound (MLSM is N^3 in most cases, N^4 in a few edge cases). This disables the load portion. Note that the way ld_hoist_st_sink.ll is written makes one think that the loads should be moved to the while.preheader block, but 1. Neither MLSM nor GVNHoist do it (they both move them to identical places). 2. MLSM couldn't possibly do it anyway, as the while.preheader block is not the head of the diamond, while.body is. (GVNHoist could do it if it was legal). 3. At a glance, it's not legal anyway because the in-loop load conflict with the in-loop store, so the loads must stay in-loop. I am happy to update the test to use update_test_checks so that checking is tighter, just was going to do it as a followup. Note that i can find no particular benefit to the store portion on any real testcase/benchmark i have (even size-wise). If we really still want it, i am happy to commit to writing a targeted store sinker, just taking the code from the MemorySSA port of MergedLoadStoreMotion (which is N^2 worst case, and N most of the time). We can do what it does in a much better time bound. We also should be both hoisting and sinking stores, not just sinking them, anyway, since whether we should hoist or sink to merge depends basically on luck of the draw of where the blockers are placed. Nonetheless, i have left it alone for now. Reviewers: chandlerc, davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29079 llvm-svn: 292971 |
||
|---|---|---|
| .. | ||
| hoist-call.ll | ||
| hoist-convergent.ll | ||
| hoist-md.ll | ||
| hoist-mssa.ll | ||
| hoist-pr20242.ll | ||
| hoist-pr22005.ll | ||
| hoist-pr28606.ll | ||
| hoist-pr28933.ll | ||
| hoist-recursive-geps.ll | ||
| hoist.ll | ||
| ld_hoist1.ll | ||
| ld_hoist_st_sink.ll | ||
| pr28626.ll | ||
| pr29031.ll | ||
| pr29034.ll | ||
| pr30216.ll | ||
| pr30499.ll | ||