[PATCH] Allow PRE to duplicate loads in LICM like loop case

[hfinkel at anl.gov]

Generally speaking, I'm in favor of this. We only loose in the case where the loop trip count is (very) small and the additional load is on a relatively-hot path through the loop. However, I think we can use BPI to filter out such cases.

> It's worth mentioning that the 'merge block' concept is essentially a specialized form of jump threading. In fact, running '-jump-threading' does help in the loop cases I've looked at. However, running jump threading also inhibits some optimizations currently performed by LoadPRE. If we have a merge point where both inputs are unavailable, PRE will currently insert a single load at the merge. Running jump threading breaks this. Keeping that case working as it does today is why we only look through merge blocks with a single unavailable predeccesor in the patch.


As a side comment, do we have a regression test covering this behavior? I believe this is a case where it is appropriate to have a regression test that runs opt -O3 (to get the default optimization pipeline), to make sure we don't disturb this current behavior. If we don't, can you please add one?


================
Comment at: lib/Transforms/Scalar/GVN.cpp:1524
@@ +1523,3 @@
+/// reload)
+static bool isLICMLike(BasicBlock* Header,
+                       SmallVector<BasicBlock *, 4>& PredBlocks,
----------------
Thoughts on whether or not it is worthwhile to use getAnalysisIfAvailable<LoopInfo> for this kind of thing instead?

http://reviews.llvm.org/D7061

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/