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.

56 lines
1.7 KiB
LLVM
Raw Normal View History

[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
[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
[NewPM] Cleanup IR printing instrumentation Being lazy with printing the banner seems hard to reason with, we should print it unconditionally first (it could also lead to duplicate banners if we have multiple functions in -filter-print-funcs). The printIR() functions were doing too many things. I separated out the call from PrintPassInstrumentation since we were essentially doing two completely separate things in printIR() from different callers. There were multiple ways to generate the name of some IR. That's all been moved to getIRName(). The printing of the IR name was also inconsistent, now it's always "IR Dump on $foo" where "$foo" is the name. For a function, it's the function name. For a loop, it's what's printed by Loop::print(), which is more detailed. For an SCC, it's the list of functions in parentheses. For a module it's "[module]", to differentiate between a possible SCC with a function called "module". To preserve D74814, we have to check if we're going to print anything at all first. This is unfortunate, but I would consider this a special case that shouldn't be handled in the core logic. Reviewed By: jamieschmeiser Differential Revision: https://reviews.llvm.org/D100231
2021-04-15 05:52:50 +08:00
; INL: IR Dump After InlinerPass on (foo, 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 @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()
[NewPM] Cleanup IR printing instrumentation Being lazy with printing the banner seems hard to reason with, we should print it unconditionally first (it could also lead to duplicate banners if we have multiple functions in -filter-print-funcs). The printIR() functions were doing too many things. I separated out the call from PrintPassInstrumentation since we were essentially doing two completely separate things in printIR() from different callers. There were multiple ways to generate the name of some IR. That's all been moved to getIRName(). The printing of the IR name was also inconsistent, now it's always "IR Dump on $foo" where "$foo" is the name. For a function, it's the function name. For a loop, it's what's printed by Loop::print(), which is more detailed. For an SCC, it's the list of functions in parentheses. For a module it's "[module]", to differentiate between a possible SCC with a function called "module". To preserve D74814, we have to check if we're going to print anything at all first. This is unfortunate, but I would consider this a special case that shouldn't be handled in the core logic. Reviewed By: jamieschmeiser Differential Revision: https://reviews.llvm.org/D100231
2021-04-15 05:52:50 +08:00
; INL: IR Dump After InlinerPass on (tester) ***
[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 @tester()
; INL-NEXT: call void @foo()
[NewPM] Cleanup IR printing instrumentation Being lazy with printing the banner seems hard to reason with, we should print it unconditionally first (it could also lead to duplicate banners if we have multiple functions in -filter-print-funcs). The printIR() functions were doing too many things. I separated out the call from PrintPassInstrumentation since we were essentially doing two completely separate things in printIR() from different callers. There were multiple ways to generate the name of some IR. That's all been moved to getIRName(). The printing of the IR name was also inconsistent, now it's always "IR Dump on $foo" where "$foo" is the name. For a function, it's the function name. For a loop, it's what's printed by Loop::print(), which is more detailed. For an SCC, it's the list of functions in parentheses. For a module it's "[module]", to differentiate between a possible SCC with a function called "module". To preserve D74814, we have to check if we're going to print anything at all first. This is unfortunate, but I would consider this a special case that shouldn't be handled in the core logic. Reviewed By: jamieschmeiser Differential Revision: https://reviews.llvm.org/D100231
2021-04-15 05:52:50 +08:00
; INL-MOD-LABEL:*** IR Dump After InlinerPass on (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()
[NewPM] Cleanup IR printing instrumentation Being lazy with printing the banner seems hard to reason with, we should print it unconditionally first (it could also lead to duplicate banners if we have multiple functions in -filter-print-funcs). The printIR() functions were doing too many things. I separated out the call from PrintPassInstrumentation since we were essentially doing two completely separate things in printIR() from different callers. There were multiple ways to generate the name of some IR. That's all been moved to getIRName(). The printing of the IR name was also inconsistent, now it's always "IR Dump on $foo" where "$foo" is the name. For a function, it's the function name. For a loop, it's what's printed by Loop::print(), which is more detailed. For an SCC, it's the list of functions in parentheses. For a module it's "[module]", to differentiate between a possible SCC with a function called "module". To preserve D74814, we have to check if we're going to print anything at all first. This is unfortunate, but I would consider this a special case that shouldn't be handled in the core logic. Reviewed By: jamieschmeiser Differential Revision: https://reviews.llvm.org/D100231
2021-04-15 05:52:50 +08:00
; INL-MOD-LABEL:*** IR Dump After InlinerPass on (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
}