The -runtime-counter-relocation switch is changed from a Boolean to a
three-way switch: none, variable, or function. The previous
-runtime-counter-relocation=true behavior is now selected with
-runtime-counter-relocation=variable. In the new ...=function mode,
instead of loading the global variable __llvm_profile_counter_bias,
instrumented code calls the function __llvm_profile_get_counter_bias
with no arguments to return the bias. This can be a runtime function or
it can be defined in the translation unit to be inlined.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
An alternative I thought of would be to always use a call and generate a (weak) implementation of __llvm_profile_counter_dynamic_bias inside each translation unit. The default generated function would simply return the variable. I'm not sure what the impact on performance would be though.
compiler-rt/include/profile/InstrProfData.inc | ||
---|---|---|
668 | It's not clear to me from this name that it refers to a function that returns the bias. How about __llvm_profile_get_counter_bias? That would match symbols like __llvm_profile_get_magic or __llvm_profile_get_version. |
I think the impact is likely to be significant in any place that the function is not inlined. It's not just the call/return overhead per se (which might well be in the noise), but it also requires immediately spilling all the argument registers in the prologue because the calling convention for the bias fetch will clobber all those registers. Without LTO, I don't think there's any possibility for a "weak inlined" definition, since inlining needs to happen early in compilation and weak vs strong definitions are not resolved one way or another until link time.
I might have missed the discussion somewhere. What the use case for the dynamic bias?
It's not clear to me from this name that it refers to a function that returns the bias. How about __llvm_profile_get_counter_bias? That would match symbols like __llvm_profile_get_magic or __llvm_profile_get_version.