f6703a4ff5
Contextual profiling identifies functions by GUID. Functions that may get overridden by the linker with a prevailing copy may have, during instrumentation, different variants in different modules. If these variants get inlined before linking (here I assume thinlto), they will identify themselves to the ctxprof runtime as their GUID, leading to issues - they may have different counter counts, for instance. If we block their inlining in the pre-thinlink compilation, only the prevailing copy will survive post-thinlink and the confusion is avoided. The change introduces a small pass just for this purpose, which marks any symbols that could be affected by the above as `noinline` (even if they were `alwaysinline`). We already carried out some inlining (via the preinliner), before instrumenting, so technically the `alwaysinline` directives were honored. We could later (different patch) choose to mark them back to their original attribute (none or `alwaysinline`) post-thinlink, if we want to - but experimentally that doesn't really change much of the performance of the instrumented binary.
26 lines
385 B
LLVM
26 lines
385 B
LLVM
; RUN: opt -passes=noinline-nonprevailing -S < %s 2>&1 | FileCheck %s
|
|
|
|
define void @a() {
|
|
ret void
|
|
}
|
|
|
|
define void @b() #0 {
|
|
ret void
|
|
}
|
|
|
|
define weak_odr void @c() {
|
|
ret void
|
|
}
|
|
|
|
define weak_odr void @d() #0{
|
|
ret void
|
|
}
|
|
|
|
attributes #0 = { alwaysinline }
|
|
|
|
; CHECK: void @a() {
|
|
; CHECK: void @b() #0
|
|
; CHECK: void @c() #1
|
|
; CHECK: void @d() #1
|
|
; CHECK: attributes #1 = { noinline }
|