This is an archive of the discontinued LLVM Phabricator instance.

Reduce PGO Instrumentation binary and profile data size (Patch-1)
Needs ReviewPublic

Authored by davidxl on Sep 8 2015, 5:03 PM.

Details

Summary

The change includes three patches

  1. LLVM changes (Patch-1)
  2. Clang Driver changes (Patch-2)
  3. compile-rt (patch-3)

Description of the changes:

  1. The patch implements a new option -f[no]-profile-instr-with-names option. When -fno-profile-instr-with-names is turned on, the instrumentation will use function assembly name's md5 hash string (hex form) instead of the raw name as the profile identification key. With this change, binary and profile size is greatly reduced
  2. refactor of the instrumentation and compile-rt code such that Magic and Version (raw, and indexed) values for profile data is specified in one centralized place: InstrProf.h. To assist this change, compile_rt code no longer needs to hard code the version/magic values and will never be out of sync with instrumentor
  3. The 64bit version field in the header is partitioned into two parts a) the lower 32bit is used to represent the format version as before b) the upper 32bit is now used to encode feature/variants of the profile data that share the same format. In this case, it can be used to indicate if the profile contains raw name keys or md5hash keys. Another use of the bit is the late instrumentation profile data.

Diff Detail

Event Timeline

davidxl updated this revision to Diff 34280.Sep 8 2015, 5:03 PM
davidxl retitled this revision from to Reduce PGO Instrumentation binary and profile data size (Patch-1).
davidxl updated this object.
davidxl added reviewers: llvm-commits, bogner, silvas, xur.
silvas edited edge metadata.Sep 8 2015, 10:00 PM

Fundamentally, this approach is not a long-term solution to reducing PGO data size. The correct long-term solution for reducing PGO data size requires passing the binary to llvm-profdata. The approach of using name hashes is also not an incremental step towards the long-term solution. So thinking about it a bit more, I'm on the fence about whether a quick solution like this one even makes sense to do. I am very apprehensive of adding complexity to make this approach work, in particular threading information through many layers, as this is likely to get in the way of future work towards the long-term solution.

My takeaways from the RFC thread (maybe I am misunderstanding) is that we are still using the same format just with one string vs. another. We shouldn't need to rev the version and there shouldn't need to be any changes in compiler-rt or llvm. Clang can easily diagnose (as an isolated piece of logic) if the user did the pgo training run with md5 mode enabled but the md5 mode flag was not passed or vice versa (it is easy to tell if input function names are md5 sums or not as a diagnostic heuristic). It is also inconsistent for llvm-profdata to be able to be passed -function=foo for an md5 profile; the user should have to pass (truncated) md5 of the function name.

test/Instrumentation/InstrProfiling/profiling_md5hash_key.ll
5–6

This is backward from a standard md5 sum in hex. We should maintain the invariant that the resulting symbol name is a substring of a standard md5 sum. Otherwise it is very difficult to explain how to get the hash for a function.

E.g. we should be able to say "the symbol name is effectively replaced by the first half of its md5 sum in hex":

Sean:~ % echo -n 'foo' | md5             
acbd18db4cc2f85cedef654fccc4a4d8
Sean:~ % echo -n 'foo' | md5 | head -c 16
acbd18db4cc2f85c

The symbol name string should be acbd18db4cc2f85c.

thanm edited edge metadata.Sep 10 2015, 1:22 PM

I see a some new warnings when I build the code (after "arc patch D12715"):

[35/42] Building CXX object tools/clan...s/clangCodeGen.dir/CodeGenModule.cpp.o
In file included from /ssd/llvm-trunk-profinst/llvm/tools/clang/lib/CodeGen/CodeGenModule.cpp:53:
In file included from /ssd/llvm-trunk-profinst/llvm/include/llvm/ProfileData/InstrProfReader.h:20:
/ssd/llvm-trunk-profinst/llvm/include/llvm/ProfileData/InstrProf.h:111:10: warning: unused function 'getMagic' [-Wunused-function]
uint64_t getMagic<uint64_t>() {

^

/ssd/llvm-trunk-profinst/llvm/include/llvm/ProfileData/InstrProf.h:124:10: warning: unused function 'getMagic' [-Wunused-function]
uint64_t getMagic<uint32_t>() {

^
include/llvm/ProfileData/InstrProf.h
59

typo fromat -> format

include/llvm/Transforms/Instrumentation.h
87

typo funciton => function

Than, thanks for the review.

Currently there are two competing approaches to the problem with
different pros and cons. Looks like Sean and I are leaning towards the
more aggressive approach (not the one in this patch). I will write up
a summary at some point comparing the pros and cons of the two
approaches, and get feedback from others.

thanks,

David

silvas resigned from this revision.Mar 25 2020, 6:37 PM