summaryrefslogtreecommitdiff
path: root/test/Transforms/IndVarSimplify
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2014-01-23 11:23:19 +0000
committerChandler Carruth <chandlerc@gmail.com>2014-01-23 11:23:19 +0000
commitaaf44af76926c2728c0029bed31364cbb743d033 (patch)
tree046215ca097cb2f0a91132917dd6863df7d883dd /test/Transforms/IndVarSimplify
parent5eba14a04c8f7f62907973fe5f6c2e5f6d9fd121 (diff)
downloadllvm-aaf44af76926c2728c0029bed31364cbb743d033.tar.gz
llvm-aaf44af76926c2728c0029bed31364cbb743d033.tar.bz2
llvm-aaf44af76926c2728c0029bed31364cbb743d033.tar.xz
[LPM] Make LoopSimplify no longer a LoopPass and instead both a utility
function and a FunctionPass. This has many benefits. The motivating use case was to be able to compute function analysis passes *after* running LoopSimplify (to avoid invalidating them) and then to run other passes which require LoopSimplify. Specifically passes like unrolling and vectorization are critical to wire up to BranchProbabilityInfo and BlockFrequencyInfo so that they can be profile aware. For the LoopVectorize pass the only things in the way are LoopSimplify and LCSSA. This fixes LoopSimplify and LCSSA is next on my list. There are also a bunch of other benefits of doing this: - It is now very feasible to make more passes *preserve* LoopSimplify because they can simply run it after changing a loop. Because subsequence passes can assume LoopSimplify is preserved we can reduce the runs of this pass to the times when we actually mutate a loop structure. - The new pass manager should be able to more easily support loop passes factored in this way. - We can at long, long last observe that LoopSimplify is preserved across SCEV. This *halves* the number of times we run LoopSimplify!!! Now, getting here wasn't trivial. First off, the interfaces used by LoopSimplify are all over the map regarding how analysis are updated. We end up with weird "pass" parameters as a consequence. I'll try to clean at least some of this up later -- I'll have to have it all clean for the new pass manager. Next up I discovered a really frustrating bug. LoopUnroll *claims* to preserve LoopSimplify. That's actually a lie. But the way the LoopPassManager ends up running the passes, it always ran LoopSimplify on the unrolled-into loop, rectifying this oversight before any verification could kick in and point out that in fact nothing was preserved. So I've added code to the unroller to *actually* simplify the surrounding loop when it succeeds at unrolling. The only functional change in the test suite is that we now catch a case that was previously missed because SCEV and other loop transforms see their containing loops as simplified and thus don't miss some opportunities. One test case has been converted to check that we catch this case rather than checking that we miss it but at least don't get the wrong answer. Note that I have #if-ed out all of the verification logic in LoopSimplify! This is a temporary workaround while extracting these bits from the LoopPassManager. Currently, there is no way to have a pass in the LoopPassManager which preserves LoopSimplify along with one which does not. The LPM will try to verify on each loop in the nest that LoopSimplify holds but the now-Function-pass cannot distinguish what loop is being verified and so must try to verify all of them. The inner most loop is clearly no longer simplified as there is a pass which didn't even *attempt* to preserve it. =/ Once I get LCSSA out (and maybe LoopVectorize and some other fixes) I'll be able to re-enable this check and catch any places where we are still failing to preserve LoopSimplify. If this causes problems I can back this out and try to commit *all* of this at once, but so far this seems to work and allow much more incremental progress. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199884 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Transforms/IndVarSimplify')
-rw-r--r--test/Transforms/IndVarSimplify/lftr-reuse.ll10
1 files changed, 4 insertions, 6 deletions
diff --git a/test/Transforms/IndVarSimplify/lftr-reuse.ll b/test/Transforms/IndVarSimplify/lftr-reuse.ll
index fe3df5cfa8..1fdcdd1ec3 100644
--- a/test/Transforms/IndVarSimplify/lftr-reuse.ll
+++ b/test/Transforms/IndVarSimplify/lftr-reuse.ll
@@ -38,17 +38,16 @@ for.end:
ret void
}
-; It would be nice if SCEV and any loop analysis could assume that
-; preheaders exist. Unfortunately it is not always the case. This test
-; checks that SCEVExpander can handle an outer loop that has not yet
-; been simplified. As a result, the inner loop's exit test will not be
-; rewritten.
+; This test checks that SCEVExpander can handle an outer loop that has been
+; simplified, and as a result the inner loop's exit test will be rewritten.
define void @expandOuterRecurrence(i32 %arg) nounwind {
entry:
%sub1 = sub nsw i32 %arg, 1
%cmp1 = icmp slt i32 0, %sub1
br i1 %cmp1, label %outer, label %exit
+; CHECK: outer:
+; CHECK: icmp slt
outer:
%i = phi i32 [ 0, %entry ], [ %i.inc, %outer.inc ]
%sub2 = sub nsw i32 %arg, %i
@@ -60,7 +59,6 @@ inner.ph:
br label %inner
; CHECK: inner:
-; CHECK: icmp slt
; CHECK: br i1
inner:
%j = phi i32 [ 0, %inner.ph ], [ %j.inc, %inner ]