Hopefully this will make it easier for the next person to figure all
this out...
Details
- Reviewers
davidxl bogner - Commits
- rG2f36f059512f: [PGO] Comment how function pointers for indirect calls are mapped to function…
rG42a6fe199f03: [PGO] Comment how function pointers for indirect calls are mapped to function…
rCRT264612: [PGO] Comment how function pointers for indirect calls are mapped to function…
rL264612: [PGO] Comment how function pointers for indirect calls are mapped to function…
rL264611: [PGO] Comment how function pointers for indirect calls are mapped to function…
Diff Detail
- Repository
- rL LLVM
Event Timeline
lgtm
include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
76 ↗ | (On Diff #51714) | After this is committed, please update the copy of this file in compiler-rt as well. |
include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
76 ↗ | (On Diff #51714) | Done in r264612. |
llvm/trunk/include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
78 | Hmm. It is used by ProfileData/InstrProfReader.cpp So it seems that value profiling adds quite a bit size overhead to the metadata sections. |
llvm/trunk/include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
78 | Right -- it is used by the profile reader to build mapping from func->name so that indirect call target profile can be translated to func names. Changing the llvm-profdata workflow by forcing binary as an input will allow the field to be removed -- but things get complicated with -fPIE build. |
Is FunctionPointer still used by the runtime? @davidxl @vsk
I can only find one reference __llvm_get_function_addr, which is a public API.