RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 19:23:23 +01:00
Code Issues Projects Releases Wiki Activity
3884c3dc13
llvm-mirror/test/Other/loop-pm-invalidation.ll

329 lines
18 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 09:26:58 +01:00
; Test that the loop PM infrastructure is invalidated appropriately.
;
; Check that we always nuke the LPM stuff when the loops themselves are
; invalidated.
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 06:31:07 +02:00
; RUN: opt -disable-output -disable-verify -verify-cfg-preserved=0 -debug-pass-manager -aa-pipeline= %s 2>&1 \
[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 09:26:58 +01:00
; 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.
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 06:31:07 +02:00
; RUN: opt -disable-output -disable-verify -verify-cfg-preserved=0 -debug-pass-manager %s -aa-pipeline= 2>&1 \
[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 09:26:58 +01:00
; 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.
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 06:31:07 +02:00
; RUN: opt -disable-output -disable-verify -verify-cfg-preserved=0 -debug-pass-manager %s -aa-pipeline= 2>&1 \
[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 09:26:58 +01:00
; 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() {
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-LOOP-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01:00
; CHECK-LOOP-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}LoopAnalysis
; CHECK-LOOP-INV-NEXT: Invalidating 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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01:00
; CHECK-LOOP-INV-NEXT: Finished {{.*}}Function pass manager run.
;
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-SCEV-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01:00
; CHECK-SCEV-INV-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
[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 09:16:06 +01: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 09:26:58 +01:00
; CHECK-SCEV-INV-NEXT: Finished {{.*}}Function pass manager run.
entry:
ret void
}
define void @one_loop(i1* %ptr) {
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-LOOP-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 00:02:27 +02: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 09:26:58 +01: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 09:48:50 +01:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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.
;
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-SCEV-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 00:02:27 +02: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 09:26:58 +01: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 09:48:50 +01:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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) {
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-LOOP-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 00:02:27 +02: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 09:26:58 +01: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 09:48:50 +01:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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.
;
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-SCEV-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 00:02:27 +02: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 09:26:58 +01: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 09:48:50 +01:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
}
Revert "[LoopDeletion] Allows deletion of possibly infinite side-effect free loops" This reverts commit 0b17c6e4479d62bd4ff05c48d6cdf340b198832f. This patch causes a compile-time error in SCEV.
2020-11-07 06:31:35 +01:00
define void @dead_loop() {
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-LOOP-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 00:02:27 +02: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 09:26:58 +01: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 09:48:50 +01:00
; CHECK-LOOP-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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.
;
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-SCEV-INV: Starting {{.*}}Function pass manager run
[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 09:16:06 +01: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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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
Do not call Loop::getName on possibly dead loops This fixes PR34832. llvm-svn: 314938
2017-10-05 00:02:27 +02: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 09:26:58 +01: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 09:48:50 +01:00
; CHECK-SCEV-INV-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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.
;
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 02:08:24 +02:00
; CHECK-SCEV-INV-AFTER-DELETE-LABEL: Running pass: LoopSimplifyPass on dead_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 09:26:58 +01: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 09:16:06 +01: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 09:26:58 +01: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 09:48:50 +01: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 09:26:58 +01: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: Running pass: InvalidateAnalysisPass<{{.*}}ScalarEvolutionAnalysis
; 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 09:48:50 +01:00
; CHECK-SCEV-INV-AFTER-DELETE-NEXT: Invalidating analysis: InnerAnalysisManagerProxy<{{.*}}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 09:16:06 +01: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 09:26:58 +01: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
}
Reference in New Issue Copy Permalink