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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
