maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Other/loop-pm-invalidation.ll

350 lines
19 KiB
LLVM
Raw Normal View History

[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; Test that the loop PM infrastructure is invalidated appropriately.
;
; Check that we always nuke the LPM stuff when the loops themselves are
; invalidated.
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='loop(no-op-loop),invalidate<loops>,loop(no-op-loop)' \
; RUN: | FileCheck %s --check-prefix=CHECK-LOOP-INV
;
; If we ended up building the standard analyses, their invalidation should nuke
; stuff as well.
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='loop(no-op-loop),invalidate<scalar-evolution>,loop(no-op-loop)' \
; RUN: | FileCheck %s --check-prefix=CHECK-SCEV-INV
;
; Also provide a test that can delete loops after populating analyses for them.
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='loop(no-op-loop,loop-deletion),invalidate<scalar-evolution>,loop(no-op-loop)' \
; RUN: | FileCheck %s --check-prefix=CHECK-SCEV-INV-AFTER-DELETE
define void @no_loops() {
; CHECK-LOOP-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on no_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating all non-preserved analyses
; CHECK-LOOP-INV-NEXT: Invalidating analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on no_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run.
;
; CHECK-SCEV-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on no_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Invalidating all non-preserved analyses
; CHECK-SCEV-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on no_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run.
entry:
ret void
}
define void @one_loop(i1* %ptr) {
; CHECK-LOOP-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on one_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: AAManager
; CHECK-LOOP-INV-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating all non-preserved analyses
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 06:02:27 +08:00
; CHECK-LOOP-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on one_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run.
;
; CHECK-SCEV-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on one_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: AAManager
; CHECK-SCEV-INV-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Invalidating all non-preserved analyses
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 06:02:27 +08:00
; CHECK-SCEV-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on one_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run.
entry:
br label %l0.header
l0.header:
%flag0 = load volatile i1, i1* %ptr
br i1 %flag0, label %l0.header, label %exit
exit:
ret void
}
define void @nested_loops(i1* %ptr) {
; CHECK-LOOP-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on nested_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: AAManager
; CHECK-LOOP-INV-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating all non-preserved analyses
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 06:02:27 +08:00
; CHECK-LOOP-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
; CHECK-LOOP-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on nested_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run.
;
; CHECK-SCEV-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on nested_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: AAManager
; CHECK-SCEV-INV-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Invalidating all non-preserved analyses
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 06:02:27 +08:00
; CHECK-SCEV-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
; CHECK-SCEV-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on nested_loops
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run.
entry:
br label %l.0.header
l.0.header:
br label %l.0.0.header
l.0.0.header:
%flag.0.0 = load volatile i1, i1* %ptr
br i1 %flag.0.0, label %l.0.0.header, label %l.0.latch
l.0.latch:
%flag.0 = load volatile i1, i1* %ptr
br i1 %flag.0, label %l.0.header, label %exit
exit:
ret void
}
define void @dead_loop() {
; CHECK-LOOP-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on dead_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: AAManager
; CHECK-LOOP-INV-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-LOOP-INV-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating all non-preserved analyses
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 06:02:27 +08:00
; CHECK-LOOP-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on dead_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-LOOP-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: LoopAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-LOOP-INV-NEXT: Running pass: LCSSAPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-LOOP-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-LOOP-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run.
;
; CHECK-SCEV-INV-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on dead_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: LoopAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: AAManager
; CHECK-SCEV-INV-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
; CHECK-SCEV-INV-NEXT: Invalidating all non-preserved analyses
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 06:02:27 +08:00
; CHECK-SCEV-INV-NEXT: Clearing all analysis results for: <possibly invalidated loop>
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on dead_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-NEXT: Running pass: LoopSimplifyPass
; CHECK-SCEV-INV-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run.
;
; CHECK-SCEV-INV-AFTER-DELETE-LABEL: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on dead_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: LoopSimplifyPass
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: LoopAnalysis
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: AssumptionAnalysis
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: AAManager
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: TargetIRAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Starting {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: NoOpLoopPass
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: LoopDeletionPass
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Clearing all analysis results for:
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Finished {{.*}}Loop pass manager run.
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Invalidating all non-preserved analyses
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Invalidating all non-preserved analyses
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Invalidating analysis: ScalarEvolutionAnalysis
[PM] Relax the patterns used in the new test I added because some compilers don't print the typedef name. llvm-svn: 294729
2017-02-10 16:48:50 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}Loop
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}> on dead_loop
[PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
2017-12-29 16:16:06 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Starting {{.*}}Function pass manager run
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: LoopSimplifyPass
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Running pass: LCSSAPass
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Finished {{.*}}Function pass manager run
[PM] Fix a bug in the new loop PM when handling functions with no loops. Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
2017-02-10 16:26:58 +08:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Finished {{.*}}Function pass manager run.
entry:
br label %l0.header
l0.header:
br i1 false, label %l0.header, label %exit
exit:
ret void
}