maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Other/scc-pass-printer.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

75 lines
2.5 KiB
LLVM
Raw Normal View History

[test] Make scc-pass-printer.ll work with NPM Pin some legacy PM specific RUN lines to legacy PM.
2020-11-18 15:53:21 +08:00
; RUN: opt -enable-new-pm=0 < %s 2>&1 -disable-output \
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; RUN: -inline -print-after-all | FileCheck %s --check-prefix=LEGACY
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
; RUN: opt < %s 2>&1 -disable-output \
; RUN: -passes=inline -print-after-all | FileCheck %s -check-prefix=INL
; RUN: opt < %s 2>&1 -disable-output \
[llvm] Add interface to drive inlining decision using ML model Summary: This change introduces InliningAdvisor (and related APIs), the interface that abstracts decision making away from the inlining pass. We will use this interface to delegate decision making to a trained ML model, subsequently (see referenced RFC). RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html Reviewers: davidxl, eraman, dblaikie Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79042
2020-04-29 04:25:15 +08:00
; RUN: -passes=inliner-wrapper -print-after-all | FileCheck %s -check-prefix=INL
[test] Make scc-pass-printer.ll work with NPM Pin some legacy PM specific RUN lines to legacy PM.
2020-11-18 15:53:21 +08:00
; RUN: opt -enable-new-pm=0 < %s 2>&1 -disable-output \
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; RUN: -inline -print-after-all -print-module-scope | FileCheck %s -check-prefix=LEGACY-MOD
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
; RUN: opt < %s 2>&1 -disable-output \
; RUN: -passes=inline -print-after-all -print-module-scope | FileCheck %s -check-prefix=INL-MOD
[llvm] Add interface to drive inlining decision using ML model Summary: This change introduces InliningAdvisor (and related APIs), the interface that abstracts decision making away from the inlining pass. We will use this interface to delegate decision making to a trained ML model, subsequently (see referenced RFC). RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html Reviewers: davidxl, eraman, dblaikie Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79042
2020-04-29 04:25:15 +08:00
; RUN: opt < %s 2>&1 -disable-output \
; RUN: -passes=inliner-wrapper -print-after-all -print-module-scope | FileCheck %s -check-prefix=INL-MOD
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; LEGACY: IR Dump After Function Integration/Inlining
; LEGACY: define void @bar()
; LEGACY-NEXT: call void @foo()
; LEGACY: define void @foo()
; LEGACY-NEXT: call void @bar()
; LEGACY: IR Dump After Function Integration/Inlining
; LEGACY: define void @tester()
; LEGACY-NEXT: call void @foo()
; INL: IR Dump After InlinerPass *** (scc: (foo, bar))
; INL: define void @foo()
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
; INL-NEXT: call void @bar()
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; INL: define void @bar()
; INL-NEXT: call void @foo()
; INL: IR Dump After InlinerPass *** (scc: (tester))
; INL: define void @tester()
; INL-NEXT: call void @foo()
; LEGACY-MOD: IR Dump After Function Integration/Inlining
; LEGACY-MOD-NEXT: ModuleID =
; LEGACY-MOD: define void @tester()
; LEGACY-MOD: define void @foo()
; LEGACY-MOD: define void @bar()
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; INL-MOD-LABEL:*** IR Dump After InlinerPass *** (scc: (foo, bar))
Fixing -print-module-scope for legacy SCC passes It appears that print-module-scope was not implemented for legacy SCC passes. Fixed to print a whole module instead of just current SCC. Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D54793 llvm-svn: 348144
2018-12-03 22:48:15 +08:00
; INL-MOD-NEXT: ModuleID =
; INL-MOD-NEXT: source_filename =
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
; INL-MOD: define void @tester()
; INL-MOD-NEXT: call void @foo()
; INL-MOD: define void @foo()
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; INL-MOD-NEXT: call void @bar()
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
; INL-MOD: define void @bar()
[LazyCallGraph] Build SCCs of the reference graph in order ``` // The legacy PM CGPassManager discovers SCCs this way: for function in the source order tarjanSCC(function) // While the new PM CGSCCPassManager does: for function in the reversed source order [1] discover a reference graph SCC build call graph SCCs inside the reference graph SCC ``` In the common cases, reference graph ~= call graph, the new PM order is undesired because for `a | b | c` (3 independent functions), the new PM will process them in the reversed order: c, b, a. If `a <-> b <-> c`, we can see that `-print-after-all` will report the sole SCC as `scc: (c, b, a)`. This patch corrects the iteration order. The discovered SCC order will match the legacy PM in the common cases. For some tests (`Transforms/Inline/cgscc-*.ll` and `unittests/Analysis/CGSCCPassManagerTest.cpp`), the behaviors are dependent on the SCC discovery order and there are too many check lines for the particular order. This patch simply reverses the function order to avoid changing too many check lines. Differential Revision: https://reviews.llvm.org/D90566
2020-11-03 05:22:42 +08:00
; INL-MOD-NEXT: call void @foo()
; INL-MOD-LABEL:*** IR Dump After InlinerPass *** (scc: (tester))
Fixing -print-module-scope for legacy SCC passes It appears that print-module-scope was not implemented for legacy SCC passes. Fixed to print a whole module instead of just current SCC. Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D54793 llvm-svn: 348144
2018-12-03 22:48:15 +08:00
; INL-MOD-NEXT: ModuleID =
; INL-MOD-NEXT: source_filename =
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
; INL-MOD: define void @tester()
; INL-MOD-NEXT: call void @foo()
; INL-MOD: define void @foo()
; INL-MOD-NEXT: call void @bar()
; INL-MOD: define void @bar()
; INL-MOD-NEXT: call void @foo()
; INL-MOD: IR Dump After
Fixing -print-module-scope for legacy SCC passes It appears that print-module-scope was not implemented for legacy SCC passes. Fixed to print a whole module instead of just current SCC. Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D54793 llvm-svn: 348144
2018-12-03 22:48:15 +08:00
; INL-MOD-NEXT: ModuleID =
; INL-MOD-NEXT: source_filename =
; INL-MOD-NOT: Printing <null> Function
[NewPM] implement SCC printing for -print-before-all/-print-after-all Removing deficiency of initial implementation of -print-before-all/-after-all - it was effectively skipping IR printing for all the SCC passes. Now LazyCallGraph:SCC gets its IR printed. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D53270 llvm-svn: 344505
2018-10-15 18:46:35 +08:00
define void @tester() noinline {
call void @foo()
ret void
}
define void @foo() noinline {
call void @bar()
ret void
}
define void @bar() noinline {
call void @foo()
ret void
}