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/time-passes.ll

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

70 lines
3.0 KiB
LLVM
Raw Normal View History

[PassTiming] reporting time-passes separately for multiple pass instances of the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
2018-09-04 14:12:28 +08:00
; RUN: opt < %s -disable-output -instcombine -instcombine -licm -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-LEGACY
[New PM][PassTiming] implement -time-passes for the new pass manager Enable time-passes functionality through PassInstrumentation callbacks for passes and analyses. TimePassesHandler class keeps all the callbacks, the timing data as it is being collected as well as the stack of currently active timers. Parts of the fix that might be somewhat unobvious: - mapping of passes into Timer (TimingData) can not be done per-instance. PassID name provided into the callback is common for all the pass invocations. Thus the only way to get a timing with reasonable granularity is to collect timing data per pass invocation, getting a new timer for each BeforePass. Hence the key for TimingData uses a pair of <StringRef/unsigned count> to uniquely identify a pass invocation. - consequently, this new-pass-manager implementation performs no aggregation of timing data, reporting timings for each pass invocation separately. In that it differs from legacy-pass-manager time-passes implementation that reports timing data aggregated per pass instance. - pass managers and adaptors are not tracked, similar to how pass managers are not tracked in legacy time-passes. - TimerStack tracks timers that are active, each BeforePass pushes the new timer on stack, each AfterPass pops active timer from stack and stops it. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D51276 llvm-svn: 343898
2018-10-06 06:32:01 +08:00
; RUN: opt < %s -disable-output -instcombine -instcombine -licm -licm -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-LEGACY --check-prefix=TIME-DOUBLE-LICM-LEGACY
; RUN: opt < %s -disable-output -passes='instcombine,instcombine,loop(licm)' -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-NEW
; RUN: opt < %s -disable-output -passes='instcombine,loop(licm),instcombine,loop(licm)' -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-NEW -check-prefix=TIME-DOUBLE-LICM-NEW
; RUN: opt < %s -disable-output -passes='default<O2>' -time-passes 2>&1 | FileCheck %s --check-prefix=TIME
[NFC][PassTiming] factor out generic PassTimingInfo Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
2018-08-29 05:06:51 +08:00
;
[TimePasses] allow -time-passes reporting into a custom stream TimePassesHandler object (implementation of time-passes for new pass manager) gains ability to report into a stream customizable per-instance (per pipeline). Intended use is to specify separate time-passes output stream per each compilation, setting up TimePasses member of StandardInstrumentation during PassBuilder setup. That allows to get independent non-overlapping pass-times reports for parallel independent compilations (in JIT-like setups). By default it still puts timing reports into the info-output-file stream (created by CreateInfoOutputFile every time report is requested). Unit-test added for non-default case, and it also allowed to discover that print() does not work as declared - it did not reset the timers, leading to yet another report being printed into the default stream. Fixed print() to actually reset timers according to what was declared in print's comments before. Reviewed By: philip.pfaffe Differential Revision: https://reviews.llvm.org/D59366 llvm-svn: 356305
2019-03-16 06:15:23 +08:00
; The following 4 test runs verify -info-output-file interaction (default goes to stderr, '-' goes to stdout).
; RUN: opt < %s -disable-output -O2 -time-passes -info-output-file='-' 2>/dev/null | FileCheck %s --check-prefix=TIME
; RUN: opt < %s -disable-output -passes='default<O2>' -time-passes -info-output-file='-' 2>/dev/null | FileCheck %s --check-prefix=TIME
;
; RUN: rm -f %t; opt < %s -disable-output -O2 -time-passes -info-output-file=%t
; RUN: cat %t | FileCheck %s --check-prefix=TIME
;
; RUN: rm -f %t; opt < %s -disable-output -passes='default<O2>' -time-passes -info-output-file=%t
; RUN: cat %t | FileCheck %s --check-prefix=TIME
;
[NFC][PassTiming] factor out generic PassTimingInfo Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
2018-08-29 05:06:51 +08:00
; TIME: Pass execution timing report
; TIME: Total Execution Time:
; TIME: Name
[NFC] correcting patterns in time-passes test to fix buildbot llvm-svn: 341348
2018-09-04 16:21:37 +08:00
; TIME-LEGACY-DAG: Combine redundant instructions{{$}}
[PassTiming] reporting time-passes separately for multiple pass instances of the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
2018-09-04 14:12:28 +08:00
; TIME-LEGACY-DAG: Combine redundant instructions #2
[NFC] correcting patterns in time-passes test to fix buildbot llvm-svn: 341348
2018-09-04 16:21:37 +08:00
; TIME-LEGACY-DAG: Loop Invariant Code Motion{{$}}
[New PM][PassTiming] implement -time-passes for the new pass manager Enable time-passes functionality through PassInstrumentation callbacks for passes and analyses. TimePassesHandler class keeps all the callbacks, the timing data as it is being collected as well as the stack of currently active timers. Parts of the fix that might be somewhat unobvious: - mapping of passes into Timer (TimingData) can not be done per-instance. PassID name provided into the callback is common for all the pass invocations. Thus the only way to get a timing with reasonable granularity is to collect timing data per pass invocation, getting a new timer for each BeforePass. Hence the key for TimingData uses a pair of <StringRef/unsigned count> to uniquely identify a pass invocation. - consequently, this new-pass-manager implementation performs no aggregation of timing data, reporting timings for each pass invocation separately. In that it differs from legacy-pass-manager time-passes implementation that reports timing data aggregated per pass instance. - pass managers and adaptors are not tracked, similar to how pass managers are not tracked in legacy time-passes. - TimerStack tracks timers that are active, each BeforePass pushes the new timer on stack, each AfterPass pops active timer from stack and stops it. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D51276 llvm-svn: 343898
2018-10-06 06:32:01 +08:00
; TIME-DOUBLE-LICM-LEGACY-DAG: Loop Invariant Code Motion #2
[PassTiming] reporting time-passes separately for multiple pass instances of the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
2018-09-04 14:12:28 +08:00
; TIME-LEGACY-DAG: Scalar Evolution Analysis
; TIME-LEGACY-DAG: Loop-Closed SSA Form Pass
; TIME-LEGACY-DAG: LCSSA Verifier
; TIME-LEGACY-DAG: Canonicalize natural loops
; TIME-LEGACY-DAG: Natural Loop Information
[NFC][PassTiming] factor out generic PassTimingInfo Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
2018-08-29 05:06:51 +08:00
; TIME-LEGACY-DAG: Dominator Tree Construction
; TIME-LEGACY-DAG: Module Verifier
; TIME-LEGACY-DAG: Target Library Information
[New PM][PassTiming] implement -time-passes for the new pass manager Enable time-passes functionality through PassInstrumentation callbacks for passes and analyses. TimePassesHandler class keeps all the callbacks, the timing data as it is being collected as well as the stack of currently active timers. Parts of the fix that might be somewhat unobvious: - mapping of passes into Timer (TimingData) can not be done per-instance. PassID name provided into the callback is common for all the pass invocations. Thus the only way to get a timing with reasonable granularity is to collect timing data per pass invocation, getting a new timer for each BeforePass. Hence the key for TimingData uses a pair of <StringRef/unsigned count> to uniquely identify a pass invocation. - consequently, this new-pass-manager implementation performs no aggregation of timing data, reporting timings for each pass invocation separately. In that it differs from legacy-pass-manager time-passes implementation that reports timing data aggregated per pass instance. - pass managers and adaptors are not tracked, similar to how pass managers are not tracked in legacy time-passes. - TimerStack tracks timers that are active, each BeforePass pushes the new timer on stack, each AfterPass pops active timer from stack and stops it. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D51276 llvm-svn: 343898
2018-10-06 06:32:01 +08:00
; TIME-NEW-DAG: InstCombinePass #1
; TIME-NEW-DAG: InstCombinePass #2
; TIME-NEW-DAG: InstCombinePass #3
; TIME-NEW-DAG: InstCombinePass #4
; TIME-NEW-DAG: LICMPass #1
; TIME-NEW-DAG: LICMPass #2
; TIME-NEW-DAG: LICMPass #3
; TIME-DOUBLE-LICM-NEW-DAG: LICMPass #4
; TIME-DOUBLE-LICM-NEW-DAG: LICMPass #5
; TIME-DOUBLE-LICM-NEW-DAG: LICMPass #6
; TIME-NEW-DAG: LCSSAPass
; TIME-NEW-DAG: LoopSimplifyPass
; TIME-NEW-DAG: ScalarEvolutionAnalysis
; TIME-NEW-DAG: LoopAnalysis
; TIME-NEW-DAG: VerifierPass
; TIME-NEW-DAG: DominatorTreeAnalysis
; TIME-NEW-DAG: TargetLibraryAnalysis
NFC. fixing time-passes test failure on Windows. llvm-svn: 340893
2018-08-29 11:53:30 +08:00
; TIME: Total{{$}}
[NFC][PassTiming] factor out generic PassTimingInfo Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
2018-08-29 05:06:51 +08:00
define i32 @foo() {
%res = add i32 5, 4
[PassTiming] reporting time-passes separately for multiple pass instances of the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
2018-09-04 14:12:28 +08:00
br label %loop1
loop1:
br i1 false, label %loop1, label %end
end:
[NFC][PassTiming] factor out generic PassTimingInfo Moving PassTimingInfo from legacy pass manager code into a separate header. Making it suitable for both legacy and new pass manager. Adding a test on -time-passes main functionality. llvm-svn: 340872
2018-08-29 05:06:51 +08:00
ret i32 %res
}
[PassTiming] reporting time-passes separately for multiple pass instances of the same pass Summary: Refactoring done by rL340872 accidentally appeared to be non-NFC, changing the way how multiple instances of the same pass are handled - aggregation of results by PassName forced data for multiple instances to be merged together and reported as one line. Getting back to creating/reporting timers per pass instance. Reporting was a bit enhanced by counting pass instances and adding #<num> suffix to the pass description. Note that it is instances that are being counted, not invocations of them. time-passes test updated to account for multiple passes being run. Reviewers: paquette, jhenderson, MatzeB, skatkov Reviewed By: skatkov Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51535 llvm-svn: 341346
2018-09-04 14:12:28 +08:00
define void @bar_with_loops() {
br label %loop1
loop1:
br i1 false, label %loop1, label %loop2
loop2:
br i1 true, label %loop2, label %end
end:
ret void
}