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

Tue Mar 23 12:03:11 PDT 2021

phosek added a comment.

In D98061#2623959 <https://reviews.llvm.org/D98061#2623959>, @MaskRay wrote:

> I am a bit concerned that whether the file is generated or not is now dependent on the instrumentation and linker garbage collection.

That's a fair concern, do you know about use cases where this would cause issues?

>> 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.
>
> The overhead is just `__llvm_profile_write_file`, right? It just writes a 100+ bytes file which has very little overhead.

It could be more if you use the continuous mode where you'd also need to `mmap` the profile and do some additional setup.

> Some sanitizers can be used in a link-only manner without instrumentation, e.g. `-fsanitize=leak` does not need instrumentation. The source code just loses `__has_feature(leak_sanitizer)` detection. 
> Link-only `-fsanitize=address` can catch double free and mismatching new/delete.
>
> Do we expect that libclang_rt.profile- can provide other features which may be useful even if there is nothing to instrument according to `-fprofile-list`?

I'm not aware of any such features being planned right now.

> If yes, making the library conditionally not linked can lose such features.
>
> Another case is `ld.lld --thinlto-index-only` always creates `*.imports` and `*.thinlto.bc` files, to convey to the build system that the files are correctly generated.

Since each instrumented binary (that is executable and shared library) generates its own profile, how many profiles get generated really depends on how many instrumented shared libraries your binary depends on. Furthermore, if you use profile merging, you cannot even predict what the profile names are going to be, so I assumed that build systems/test runners would need some other mechanism to find out what profiles were generated, at least that's the case for us.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98061