maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Profile/c-ternary.c

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

16 lines
761 B
C
Raw Normal View History

Retry: [profiling] Fix profile counter increment when emitting selects (PR32019) 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
2017-02-25 14:35:45 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-macosx10.11.0 -x c %s -o - -emit-llvm -fprofile-instrument=clang | FileCheck %s
// PR32019: Clang can lower some ternary operator expressions to select
// instructions. Make sure we only increment the profile counter for the
// condition when the condition evaluates to true.
[test] Add {{.*}} to make tests immune to dso_local/dso_preemptable/(none) differences For a definition (of most linkage types), dso_local is set for ELF -fno-pic/-fpie and COFF, but not for Mach-O. This nuance causes unneeded binary format differences. This patch replaces (function) `define ` with `define{{.*}} `, (variable/constant/alias) `= ` with `={{.*}} `, or inserts appropriate `{{.*}} ` if there is an explicit linkage. * Clang will set dso_local for Mach-O, which is currently implied by TargetMachine.cpp. This will make COFF/Mach-O and executable ELF similar. * Eventually I hope we can make dso_local the textual LLVM IR default (write explicit "dso_preemptable" when applicable) and -fpic ELF will be similar to everything else. This patch helps move toward that goal.
2020-12-31 12:45:56 +08:00
// CHECK-LABEL: define{{.*}} i32 @f1
Retry: [profiling] Fix profile counter increment when emitting selects (PR32019) 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
2017-02-25 14:35:45 +08:00
int f1(int x) {
[InstrProf] Use i32 for GEP index from lowering llvm.instrprof.increment The `llvm.instrprof.increment` intrinsic uses `i32` for the index. We should use this same type for the index into the GEP instructions. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114268
2021-11-20 07:44:48 +08:00
// CHECK: [[TOBOOL:%.*]] = icmp ne i32 %{{.*}}, 0
// CHECK-NEXT: [[STEP:%.*]] = zext i1 [[TOBOOL]] to i64
// CHECK-NEXT: [[COUNTER:%.*]] = load i64, i64* getelementptr inbounds ([2 x i64], [2 x i64]* @__profc_f1, i32 0, i32 1)
// CHECK-NEXT: add i64 [[COUNTER]], [[STEP]]
// CHECK: [[COND:%.*]] = select i1 [[TOBOOL]], i32 0, i32 1
Retry: [profiling] Fix profile counter increment when emitting selects (PR32019) 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
2017-02-25 14:35:45 +08:00
return x ? 0 : 1;
// CHECK: ret i32 [[COND]]
}