This patch adds support for generating a call graph profile from Branch Frequency Info and embedding that profile into an object file to pass to the linker. Linker support for this feature (without reading from the object file) is being reviewed at https://reviews.llvm.org/D36351 and appears to be nearing completion.
Generating the CG Profile
The CGProfile module pass simply gets the block profile count for each BB and scans for call instructions. For each call instruction it adds an edge from the current function to the called function with the current BB block profile count as the weight.
After scanning all the functions, it generates an appending module flag containing the data. The format looks like:
!llvm.module.flags = !{!0} !0 = !{i32 5, !"CG Profile", !1} !1 = !{!2, !3, !4} ; List of edges !2 = !{!"a", !"b", i64 32} ; Edge from a to b with a weight of 32 !3 = !{!"freq", !"a", i64 11} !4 = !{!"freq", !"b", i64 20}
Object FIle Representation
At codegen time this is emitted into the ELF file a pair of symbol indices and a weight. In assembly it looks like:
.cg_profile a, b, 32 .cg_profile freq, a, 11 .cg_profile freq, b, 20
When writing an ELF file these are put into a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight).
This seems a little weird. In addition to the cases you mentioned, it would also seem to imply that code like this:
will cause bar to become STB_WEAK. I guess the idea behind setting the binding to STB_WEAKrather than STB_GLOBAL is that you don't want to cause an undefined symbol error in the case where all other object files use STB_WEAK for the symbol and one of those object files contains a relocation to the symbol? In that case, maybe we should only end up setting the binding to weak if we don't emit any relocations for the symbol (i.e. isUsedInReloc() is false)?