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/optimization-remarks-auto.ll

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

85 lines
2.8 KiB
LLVM
Raw Normal View History

[Remarks][2/2] Expand remarks hotness threshold option support in more tools This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary. Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs: | profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold | In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated. Differential Revision: https://reviews.llvm.org/D85808
2020-11-18 02:43:02 +08:00
;; This test verifies 'auto' hotness threshold when profile summary is available.
;;
;; new PM
; RUN: rm -f %t.yaml %t.hot.yaml
; RUN: opt < %s --disable-output --enable-new-pm \
; RUN: --passes='inline' \
; RUN: --pass-remarks-output=%t.yaml --pass-remarks-filter='inline' \
; RUN: --pass-remarks-with-hotness
; RUN: FileCheck %s -check-prefix=YAML-PASS < %t.yaml
; RUN: FileCheck %s -check-prefix=YAML-MISS < %t.yaml
;; test 'auto' threshold
[InlineCost] Make cost-benefit decision explicit With cost-benefit analysis for inlining, we bypass the cost-threshold by returning inline result from call analyzer early. However the cost and threshold are still available from call analyzer, and when cost is actually higher than threshold, we incorrect set the reason. The change makes the decision from cost-benefit analysis explicit. It's mostly NFC, except that it allows the priority-based sample loader inliner used by CSSPGO to use cost-benefit heuristic. Differential Revision: https://reviews.llvm.org/D99302
2021-03-25 05:33:45 +08:00
; RUN: opt < %s --disable-output --enable-new-pm --inline-enable-cost-benefit-analysis=0 \
[Remarks][2/2] Expand remarks hotness threshold option support in more tools This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary. Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs: | profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold | In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated. Differential Revision: https://reviews.llvm.org/D85808
2020-11-18 02:43:02 +08:00
; RUN: --passes='module(print-profile-summary,cgscc(inline))' \
; RUN: --pass-remarks-output=%t.hot.yaml --pass-remarks-filter='inline' \
; RUN: --pass-remarks-with-hotness --pass-remarks-hotness-threshold=auto 2>&1 | FileCheck %s
; RUN: FileCheck %s -check-prefix=YAML-PASS < %t.hot.yaml
; RUN: not FileCheck %s -check-prefix=YAML-MISS < %t.hot.yaml
[InlineCost] Make cost-benefit decision explicit With cost-benefit analysis for inlining, we bypass the cost-threshold by returning inline result from call analyzer early. However the cost and threshold are still available from call analyzer, and when cost is actually higher than threshold, we incorrect set the reason. The change makes the decision from cost-benefit analysis explicit. It's mostly NFC, except that it allows the priority-based sample loader inliner used by CSSPGO to use cost-benefit heuristic. Differential Revision: https://reviews.llvm.org/D99302
2021-03-25 05:33:45 +08:00
; RUN: opt < %s --disable-output --enable-new-pm --inline-enable-cost-benefit-analysis=0 \
[Remarks][2/2] Expand remarks hotness threshold option support in more tools This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary. Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs: | profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold | In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated. Differential Revision: https://reviews.llvm.org/D85808
2020-11-18 02:43:02 +08:00
; RUN: --passes='module(print-profile-summary,cgscc(inline))' \
; RUN: --pass-remarks=inline --pass-remarks-missed=inline --pass-remarks-analysis=inline \
; RUN: --pass-remarks-with-hotness --pass-remarks-hotness-threshold=auto 2>&1 | FileCheck %s -check-prefix=CHECK-RPASS
; YAML-PASS: --- !Passed
; YAML-PASS-NEXT: Pass: inline
; YAML-PASS-NEXT: Name: Inlined
; YAML-PASS-NEXT: Function: caller1
; YAML-PASS-NEXT: Hotness: 400
; YAML-MISS: --- !Missed
; YAML-MISS-NEXT: Pass: inline
; YAML-MISS-NEXT: Name: NeverInline
; YAML-MISS-NEXT: Function: caller2
; YAML-MISS-NEXT: Hotness: 1
[InlineAdvisor] Add single quotes around caller/callee names Clang diagnostics refer to identifier names in quotes. This patch makes inline remarks conform to the convention. New behavior: ``` % clang -O2 -Rpass=inline -Rpass-missed=inline -S a.c a.c:4:25: remark: 'foo' inlined into 'bar' with (cost=-30, threshold=337) at callsite bar:0:25; [-Rpass=inline] int bar(int a) { return foo(a); } ^ ``` Reviewed By: hoy Differential Revision: https://reviews.llvm.org/D107791
2021-08-11 02:51:31 +08:00
; CHECK-RPASS: 'callee1' inlined into 'caller1' with (cost=-30, threshold=4500) (hotness: 400)
; CHECK-RPASS-NOT: 'callee2' not inlined into 'caller2' because it should never be inlined (cost=never): noinline function attribute (hotness: 1)
[Remarks][2/2] Expand remarks hotness threshold option support in more tools This is the #2 of 2 changes that make remarks hotness threshold option available in more tools. The changes also allow the threshold to sync with hotness threshold from profile summary with special value 'auto'. This change expands remarks hotness threshold option -fdiagnostics-hotness-threshold in clang and *-remarks-hotness-threshold in other tools to utilize hotness threshold from profile summary. Remarks hotness filtering relies on several driver options. Table below lists how different options are correlated and affect final remarks outputs: | profile | hotness | threshold | remarks printed | |---------|---------|-----------|-----------------| | No | No | No | All | | No | No | Yes | None | | No | Yes | No | All | | No | Yes | Yes | None | | Yes | No | No | All | | Yes | No | Yes | None | | Yes | Yes | No | All | | Yes | Yes | Yes | >=threshold | In the presence of profile summary, it is often more desirable to directly use the hotness threshold from profile summary. The new argument value 'auto' indicates threshold will be synced with hotness threshold from profile summary during compilation. The "auto" threshold relies on the availability of profile summary. In case of missing such information, no remarks will be generated. Differential Revision: https://reviews.llvm.org/D85808
2020-11-18 02:43:02 +08:00
define void @callee1() !prof !20 {
; CHECK: callee1 :hot
entry:
ret void
}
; Function Attrs: noinline
define void @callee2() noinline !prof !21 {
; CHECK: callee2 :cold
entry:
ret void
}
define void @caller1() !prof !20 {
; CHECK: caller1 :hot
entry:
call void @callee1()
ret void
}
define void @caller2() !prof !21 {
; CHECK: caller2 :cold
entry:
call void @callee2()
ret void
}
!llvm.module.flags = !{!1}
!20 = !{!"function_entry_count", i64 400}
!21 = !{!"function_entry_count", i64 1}
!1 = !{i32 1, !"ProfileSummary", !2}
!2 = !{!3, !4, !5, !6, !7, !8, !9, !10}
!3 = !{!"ProfileFormat", !"InstrProf"}
!4 = !{!"TotalCount", i64 10000}
!5 = !{!"MaxCount", i64 10}
!6 = !{!"MaxInternalCount", i64 1}
!7 = !{!"MaxFunctionCount", i64 1000}
!8 = !{!"NumCounts", i64 3}
!9 = !{!"NumFunctions", i64 3}
!10 = !{!"DetailedSummary", !11}
!11 = !{!12, !13, !14}
!12 = !{i32 10000, i64 100, i32 1}
!13 = !{i32 999000, i64 100, i32 1}
!14 = !{i32 999999, i64 1, i32 2}