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-linkage.c

39 lines
3.5 KiB
C
Raw Normal View History

PGO: Statically generate data structures In instrumentation-based profiling, we need a set of data structures to represent the counters. Previously, these were built up during static initialization. Now, they're shoved into a specially-named section so that they show up as an array. As a consequence of the reorganizing symbols, instrumentation data structures for linkonce functions are now correctly coalesced. This is the first step in a larger project to minimize runtime overhead and dependencies in instrumentation-based profilng. The larger picture includes removing all initialization overhead and making the dependency on libc optional. <rdar://problem/15943240> llvm-svn: 204080
2014-03-18 05:18:30 +08:00
// Check the data structures emitted by instrumentation.
// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name c-linkage.c %s -o - -emit-llvm -fprofile-instr-generate | FileCheck %s
InstrProf: Set profile data to visibility hidden Shared objects are fairly broken for InstrProf right now -- a follow-up commit in compiler-rt will fix the rest of this. The main problem here is that at link time, profile data symbols in the shared object might get used instead of symbols from the main executable, creating invalid profile data sections. <rdar://problem/16918688> llvm-svn: 208939
2014-05-16 09:24:00 +08:00
// CHECK: @__llvm_profile_name_foo = hidden constant [3 x i8] c"foo", section "__DATA,__llvm_prf_names", align 1
InstrProf: Use LLVM's -instrprof pass for profiling The logic for lowering profiling counters has been moved to an LLVM pass. Emit the intrinsics rather than duplicating the whole pass in clang. llvm-svn: 223683
2014-12-09 03:04:51 +08:00
// CHECK: @__llvm_profile_name_foo_weak = weak hidden constant [8 x i8] c"foo_weak", section "__DATA,__llvm_prf_names", align 1
// CHECK: @__llvm_profile_name_main = hidden constant [4 x i8] c"main", section "__DATA,__llvm_prf_names", align 1
// CHECK: @"__llvm_profile_name_c-linkage.c:foo_internal" = internal constant [24 x i8] c"c-linkage.c:foo_internal", section "__DATA,__llvm_prf_names", align 1
// CHECK: @__llvm_profile_counters_foo = hidden global [1 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
InstrProf: Set profile data to visibility hidden Shared objects are fairly broken for InstrProf right now -- a follow-up commit in compiler-rt will fix the rest of this. The main problem here is that at link time, profile data symbols in the shared object might get used instead of symbols from the main executable, creating invalid profile data sections. <rdar://problem/16918688> llvm-svn: 208939
2014-05-16 09:24:00 +08:00
// CHECK: @__llvm_profile_data_foo = hidden constant { i32, i32, i64, i8*, i64* } { i32 3, i32 1, i64 {{[0-9]+}}, i8* getelementptr inbounds ([3 x i8]* @__llvm_profile_name_foo, i32 0, i32 0), i64* getelementptr inbounds ([1 x i64]* @__llvm_profile_counters_foo, i32 0, i32 0) }, section "__DATA,__llvm_prf_data", align 8
PGO: Statically generate data structures In instrumentation-based profiling, we need a set of data structures to represent the counters. Previously, these were built up during static initialization. Now, they're shoved into a specially-named section so that they show up as an array. As a consequence of the reorganizing symbols, instrumentation data structures for linkonce functions are now correctly coalesced. This is the first step in a larger project to minimize runtime overhead and dependencies in instrumentation-based profilng. The larger picture includes removing all initialization overhead and making the dependency on libc optional. <rdar://problem/15943240> llvm-svn: 204080
2014-03-18 05:18:30 +08:00
void foo(void) { }
InstrProf: Set profile data to visibility hidden Shared objects are fairly broken for InstrProf right now -- a follow-up commit in compiler-rt will fix the rest of this. The main problem here is that at link time, profile data symbols in the shared object might get used instead of symbols from the main executable, creating invalid profile data sections. <rdar://problem/16918688> llvm-svn: 208939
2014-05-16 09:24:00 +08:00
// CHECK: @__llvm_profile_counters_foo_weak = weak hidden global [5 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
// CHECK: @__llvm_profile_data_foo_weak = weak hidden constant { i32, i32, i64, i8*, i64* } { i32 8, i32 5, i64 {{[0-9]+}}, i8* getelementptr inbounds ([8 x i8]* @__llvm_profile_name_foo_weak, i32 0, i32 0), i64* getelementptr inbounds ([5 x i64]* @__llvm_profile_counters_foo_weak, i32 0, i32 0) }, section "__DATA,__llvm_prf_data", align 8
PGO: Statically generate data structures In instrumentation-based profiling, we need a set of data structures to represent the counters. Previously, these were built up during static initialization. Now, they're shoved into a specially-named section so that they show up as an array. As a consequence of the reorganizing symbols, instrumentation data structures for linkonce functions are now correctly coalesced. This is the first step in a larger project to minimize runtime overhead and dependencies in instrumentation-based profilng. The larger picture includes removing all initialization overhead and making the dependency on libc optional. <rdar://problem/15943240> llvm-svn: 204080
2014-03-18 05:18:30 +08:00
void foo_weak(void) __attribute__((weak));
void foo_weak(void) { if (0){} if (0){} if (0){} if (0){} }
InstrProf: Set profile data to visibility hidden Shared objects are fairly broken for InstrProf right now -- a follow-up commit in compiler-rt will fix the rest of this. The main problem here is that at link time, profile data symbols in the shared object might get used instead of symbols from the main executable, creating invalid profile data sections. <rdar://problem/16918688> llvm-svn: 208939
2014-05-16 09:24:00 +08:00
// CHECK: @__llvm_profile_counters_main = hidden global [1 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
// CHECK: @__llvm_profile_data_main = hidden constant { i32, i32, i64, i8*, i64* } { i32 4, i32 1, i64 {{[0-9]+}}, i8* getelementptr inbounds ([4 x i8]* @__llvm_profile_name_main, i32 0, i32 0), i64* getelementptr inbounds ([1 x i64]* @__llvm_profile_counters_main, i32 0, i32 0) }, section "__DATA,__llvm_prf_data", align 8
PGO: Statically generate data structures In instrumentation-based profiling, we need a set of data structures to represent the counters. Previously, these were built up during static initialization. Now, they're shoved into a specially-named section so that they show up as an array. As a consequence of the reorganizing symbols, instrumentation data structures for linkonce functions are now correctly coalesced. This is the first step in a larger project to minimize runtime overhead and dependencies in instrumentation-based profilng. The larger picture includes removing all initialization overhead and making the dependency on libc optional. <rdar://problem/15943240> llvm-svn: 204080
2014-03-18 05:18:30 +08:00
static void foo_internal(void);
int main(void) {
foo();
foo_internal();
foo_weak();
return 0;
}
InstrProf: Use the same names for variables as we use in the profile There's no need to use different names for the local variables than we use in the profile itself, and it's a bit simpler and easier to debug if we're consistent. llvm-svn: 223173
2014-12-03 07:15:30 +08:00
// CHECK: @"__llvm_profile_counters_c-linkage.c:foo_internal" = internal global [3 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
// CHECK: @"__llvm_profile_data_c-linkage.c:foo_internal" = internal constant { i32, i32, i64, i8*, i64* } { i32 24, i32 3, i64 {{[0-9]+}}, i8* getelementptr inbounds ([24 x i8]* @"__llvm_profile_name_c-linkage.c:foo_internal", i32 0, i32 0), i64* getelementptr inbounds ([3 x i64]* @"__llvm_profile_counters_c-linkage.c:foo_internal", i32 0, i32 0) }, section "__DATA,__llvm_prf_data", align 8
PGO: Statically generate data structures In instrumentation-based profiling, we need a set of data structures to represent the counters. Previously, these were built up during static initialization. Now, they're shoved into a specially-named section so that they show up as an array. As a consequence of the reorganizing symbols, instrumentation data structures for linkonce functions are now correctly coalesced. This is the first step in a larger project to minimize runtime overhead and dependencies in instrumentation-based profilng. The larger picture includes removing all initialization overhead and making the dependency on libc optional. <rdar://problem/15943240> llvm-svn: 204080
2014-03-18 05:18:30 +08:00
static void foo_internal(void) { if (0){} if (0){} }
InstrProf: Use LLVM's -instrprof pass for profiling The logic for lowering profiling counters has been moved to an LLVM pass. Emit the intrinsics rather than duplicating the whole pass in clang. llvm-svn: 223683
2014-12-09 03:04:51 +08:00
// CHECK: @__llvm_profile_runtime = external global i32
// CHECK: @llvm.used = appending global [5 x i8*] [i8* bitcast ({ i32, i32, i64, i8*, i64* }* @__llvm_profile_data_foo to i8*), i8* bitcast ({ i32, i32, i64, i8*, i64* }* @__llvm_profile_data_foo_weak to i8*), i8* bitcast ({ i32, i32, i64, i8*, i64* }* @__llvm_profile_data_main to i8*), i8* bitcast ({ i32, i32, i64, i8*, i64* }* @"__llvm_profile_data_c-linkage.c:foo_internal" to i8*), i8* bitcast (i32 ()* @__llvm_profile_runtime_user to i8*)], section "llvm.metadata"
InstrProf: Emit runtime hook directly in IRGen -u behaviour is apparently not portable between linkers (see cfe-commits discussions for r204379 and r205012). I've moved the logic to IRGen, where it should have been in the first place. I don't have a Linux system to test this on, so it's possible this logic *still* doesn't pull in the instrumented profiling runtime on Linux. I'm in the process of getting tests going on the compiler-rt side (llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once we have tests for the full flow there, the runtime logic should get a whole lot less brittle. <rdar://problem/16458307> llvm-svn: 205023
2014-03-29 01:53:22 +08:00
// CHECK: define linkonce_odr i32 @__llvm_profile_runtime_user() {{.*}} {
// CHECK: %[[REG:.*]] = load i32* @__llvm_profile_runtime
// CHECK: ret i32 %[[REG]]
// CHECK: }