[PATCH] D98061: [InstrProfiling] Generate runtime hook for ELF platforms

Tue Mar 9 22:49:09 PST 2021

phosek added a comment.

In D98061#2615575 <https://reviews.llvm.org/D98061#2615575>, @davidxl wrote:

> Is the case when there is no counters very rare?  And for those cases, how much overhead the runtime hook can incur?  I assume it is small compared with actual instrumentation?

I'll try to explain our use case in more detail, hopefully that'll make the issue more clear.

We're collecting coverage during pre-submit testing and we're trying to reduce the overhead of instrumentation to provide fast turnaround time, so we're only instrumenting modified code. So if a patch modifies the header `foo.h`, we'd generate `profile.list` with the following content:

  src:include/foo.h

and set the global flag `-fprofile-list=profile.list` (because we don't know what are all the places where `foo.h` is included). For binaries that contain TUs that include `foo.h`, those TUs get instrumented and the profile runtime is linked in into the binary as expected.

There are also going to be binaries in our system build that don't use `foo.h` and ideally shouldn't have any overhead since nothing inside them is instrumented (they should behave as if `-fprofile-instr-generate` wasn't set for them at all). That's not the case today because if you set `-fprofile-instr-generate`, driver passes `-u__llvm_profile_runtime` to the linker which "pulls in" the profile runtime introducing some extra bloat and startup overhead I described earlier.

This change is trying to address the issue by declaring `__llvm_profile_runtime` only when it's needed (that is, only when TU contains some instrumented functions) rather than doing it unconditionally in the driver where we don't yet know if the runtime will be needed or not.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98061/new/

https://reviews.llvm.org/D98061