This is an archive of the discontinued LLVM Phabricator instance.

Add a flag to remap manglings when reading profile data information.
AbandonedPublic

Authored by rsmith on Aug 24 2018, 4:38 PM.

Details

Summary

This can be used to preserve profiling information across codebase changes that have widespread impact on mangled names, but across which most profiling data should still be usable. For example, when switching from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI, or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names that should be treated as equivalent (eg, std::__1 should be treated as equivalent to std::__cxx11), and profile data will be treated as applying to a particular function if its name is equivalent to the name of a function in the profile data under the provided equivalences. See the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction profiling. We do not support remapping indirect branch target information, but all other profile data should be remapped appropriately.

Support is only added for the new pass manager. If someone wants to also add support for this for the old pass manager, doing so should be straightforward.

Diff Detail

Event Timeline

rsmith created this revision.Aug 24 2018, 4:38 PM
rsmith edited the summary of this revision. (Show Details)Aug 24 2018, 4:38 PM
rsmith updated this revision to Diff 162505.Aug 24 2018, 4:47 PM

(Tweak diff so phabricator shows clang/ and llvm/ prefixes on filenames and add more context.)

thanks for working on this.

Can you split the patch into two? One for sample PGO and one for instrumentation.

In particular, I don't see much need to do this for instrumentation based PGO, but we can defer discussion on that once the patch is split.

In particular, I don't see much need to do this for instrumentation based PGO [...]

Why not?

Can you split the patch into two? One for sample PGO and one for instrumentation.

I've split the patch up thusly:

https://reviews.llvm.org/D51246 is the common infrastructure shared by sample PGO and instrumentation-based profiling.
https://reviews.llvm.org/D51247 is the core support for remapping profiling data for instrumentation-based profiling.
https://reviews.llvm.org/D51248 is the core support for remapping profiling data for sample-based profiling.
https://reviews.llvm.org/D51249 is plumbing the relevant flag through the pass manager, LTO, etc. I can try to split that up into instrumentation vs sample profiling too, but some parts of it are common between the two, so it's not straightforward.

The remaining changes are the plumbing in Clang to add the command-line flag and pass it into LLVM, which are essentially all common to both forms of profiling.

Re "Why not":

The common use model of instrumentation based PGO and SamplePGO are quite different. The former usually uses 'fresh' profile that matches the source. If there are massive code refactoring or ABI changes, the user can simply regenerate the profile. For the latter, the profile data is usually collected from production binaries, so the source is almost always newer than the profile.

Re "Why not":

The common use model of instrumentation based PGO and SamplePGO are quite different. The former usually uses 'fresh' profile that matches the source. If there are massive code refactoring or ABI changes, the user can simply regenerate the profile. For the latter, the profile data is usually collected from production binaries, so the source is almost always newer than the profile.

Frontend-based instrumentation is designed to degrade gracefully as the source changes. I don't follow your conclusion that the profile is necessarily fresh. (I'm fine with the patch being split though.)

rsmith abandoned this revision.Oct 11 2018, 4:26 PM

The constituent pieces have all landed.