Page MenuHomePhabricator

[InstrProfiling] Add -runtime-counter-relocation=function mode
AcceptedPublic

Authored by mcgrathr on Nov 22 2021, 10:59 AM.

Details

Reviewers
phosek
davidxl
vsk
Summary

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.

Diff Detail

Event Timeline

mcgrathr created this revision.Nov 22 2021, 10:59 AM
mcgrathr requested review of this revision.Nov 22 2021, 10:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 22 2021, 10:59 AM
mcgrathr edited the summary of this revision. (Show Details)Nov 22 2021, 11:13 AM
mcgrathr updated this revision to Diff 389015.Nov 22 2021, 1:09 PM

Use a DenseMap rather than instruction name to match bias load.

mcgrathr updated this revision to Diff 389074.Nov 22 2021, 6:07 PM

second copy of InstrProfData.inc

Herald added a project: Restricted Project. · View Herald TranscriptNov 22 2021, 6:07 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
ellis added a subscriber: ellis.Nov 23 2021, 9:00 AM

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.

mcgrathr marked an inline comment as done.Nov 30 2021, 10:43 AM

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.

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.

mcgrathr updated this revision to Diff 390756.Nov 30 2021, 10:43 AM

renamed callback

mcgrathr edited the summary of this revision. (Show Details)Nov 30 2021, 10:43 AM
phosek accepted this revision.Dec 3 2021, 7:39 PM

LGTM

compiler-rt/include/profile/InstrProfData.inc
668

I'd rename the macro to match the variable as well.

llvm/test/Instrumentation/InstrProfiling/runtime-counter-relocation.ll
17
30
This revision is now accepted and ready to land.Dec 3 2021, 7:39 PM

I might have missed the discussion somewhere. What the use case for the dynamic bias?

pirama added a subscriber: pirama.Jan 28 2022, 2:32 PM