783bac7ffb
The `step` instrumentation shouldn't be treated, during use, like an `increment`. The latter is treated as a BB ID. The step isn't that, it's more of a type of value profiling. We need to distinguish between the 2 when really looking for BB IDs (==increments), and handle appropriately `step`s. In particular, we need to know when to elide them because `select`s may get elided by function cloning, if the condition of the select is statically known.
77 lines
2.8 KiB
LLVM
77 lines
2.8 KiB
LLVM
; Check that we handle `step` instrumentations. These addorn `select`s.
|
|
; We don't want to confuse the `step` with normal increments, the latter of which
|
|
; we use for BB ID-ing: we want to keep the `step`s after inlining, except if
|
|
; the `select` is elided.
|
|
;
|
|
; RUN: split-file %s %t
|
|
; RUN: llvm-ctxprof-util fromJSON --input=%t/profile.json --output=%t/profile.ctxprofdata
|
|
;
|
|
; RUN: opt -passes=ctx-instr-gen %t/example.ll -use-ctx-profile=%t/profile.ctxprofdata -S -o - | FileCheck %s --check-prefix=INSTR
|
|
; RUN: opt -passes=ctx-instr-gen,module-inline %t/example.ll -use-ctx-profile=%t/profile.ctxprofdata -S -o - | FileCheck %s --check-prefix=POST-INL
|
|
; RUN: opt -passes=ctx-instr-gen,module-inline,ctx-prof-flatten %t/example.ll -use-ctx-profile=%t/profile.ctxprofdata -S -o - | FileCheck %s --check-prefix=FLATTEN
|
|
|
|
; INSTR-LABEL: yes:
|
|
; INSTR-NEXT: call void @llvm.instrprof.increment(ptr @foo, i64 [[#]], i32 2, i32 1)
|
|
; INSTR-NEXT: call void @llvm.instrprof.callsite(ptr @foo, i64 [[#]], i32 2, i32 0, ptr @bar)
|
|
|
|
; INSTR-LABEL: no:
|
|
; INSTR-NEXT: call void @llvm.instrprof.callsite(ptr @foo, i64 [[#]], i32 2, i32 1, ptr @bar)
|
|
|
|
; INSTR-LABEL: define i32 @bar
|
|
; INSTR-NEXT: call void @llvm.instrprof.increment(ptr @bar, i64 [[#]], i32 2, i32 0)
|
|
; INSTR-NEXT: %inc =
|
|
; INSTR: %test = icmp eq i32 %t, 0
|
|
; INSTR-NEXT: %1 = zext i1 %test to i64
|
|
; INSTR-NEXT: call void @llvm.instrprof.increment.step(ptr @bar, i64 [[#]], i32 2, i32 1, i64 %1)
|
|
; INSTR-NEXT: %res = select
|
|
|
|
; POST-INL-LABEL: yes:
|
|
; POST-INL-NEXT: call void @llvm.instrprof.increment
|
|
; POST-INL: call void @llvm.instrprof.increment.step
|
|
; POST-INL-NEXT: %res.i = select
|
|
|
|
; POST-INL-LABEL: no:
|
|
; POST-INL-NEXT: call void @llvm.instrprof.increment
|
|
; POST-INL-NEXT: br label
|
|
|
|
; POST-INL-LABEL: exit:
|
|
; POST-INL-NEXT: %res = phi i32 [ %res.i, %yes ], [ 1, %no ]
|
|
|
|
; FLATTEN-LABEL: yes:
|
|
; FLATTEN: %res.i = select i1 %test.i, i32 %inc.i, i32 %dec.i, !prof ![[SELPROF:[0-9]+]]
|
|
; FLATTEN-LABEL: no:
|
|
;
|
|
; See the profile, in the "yes" case we set the step counter's value, in @bar, to 3. The total
|
|
; entry count of that BB is 4.
|
|
; ![[SELPROF]] = !{!"branch_weights", i32 3, i32 1}
|
|
|
|
;--- example.ll
|
|
define i32 @foo(i32 %t) !guid !0 {
|
|
%test = icmp slt i32 %t, 0
|
|
br i1 %test, label %yes, label %no
|
|
yes:
|
|
%res1 = call i32 @bar(i32 %t) alwaysinline
|
|
br label %exit
|
|
no:
|
|
; this will result in eliding the select in @bar, when inlined.
|
|
%res2 = call i32 @bar(i32 0) alwaysinline
|
|
br label %exit
|
|
exit:
|
|
%res = phi i32 [%res1, %yes], [%res2, %no]
|
|
ret i32 %res
|
|
}
|
|
|
|
define i32 @bar(i32 %t) !guid !1 {
|
|
%inc = add i32 %t, 1
|
|
%dec = sub i32 %t, 1
|
|
%test = icmp eq i32 %t, 0
|
|
%res = select i1 %test, i32 %inc, i32 %dec
|
|
ret i32 %res
|
|
}
|
|
|
|
!0 = !{i64 1234}
|
|
!1 = !{i64 5678}
|
|
|
|
;--- profile.json
|
|
[{"Guid":1234, "Counters":[10, 4], "Callsites":[[{"Guid": 5678, "Counters":[4,3]}],[{"Guid": 5678, "Counters":[6,6]}]]}]
|