[PATCH] D36351: [lld][ELF] Add profile guided section layout

Michael Spencer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 15 01:46:50 PST 2017


Bigcheese added inline comments.


================
Comment at: lld/ELF/Options.td:54-58
+def call_graph_profile_file: S<"call-graph-profile-file">,
+  HelpText<"Layout sections to optimize the given callgraph">;
+
+def call_graph_profile_sort: F<"call-graph-profile-sort">,
+  HelpText<"Sort sections by call graph profile information">;
----------------
Bigcheese wrote:
> ruiu wrote:
> > Bigcheese wrote:
> > > ruiu wrote:
> > > > I think these two options should be merged into one option which takes a filename as an argument and enables the feature.
> > > A text file is not the only way to get input for sorting. The input can also come from object files.
> > Yeah, that actually confused me. How a compiler can add information related to profiling data to an object file being generated? I don't think I understand how the new .note section works.
> When you do -fprofile-instr-use=<path> the compiler adds profile data from that file to the IR as metadat. The cgprofile pass uses that metadata to generate metadata for the call graph profile. It then writes that to the object file.
To clarify. Where the compiler reads `-fprofile-instr-use=<path>` is the only place the profile data can be read. It depends on the exact state of the IR at that point in translation. You can't just pass the profile data to the linker or some other tool and have it make sense of it. The cgprofile pass runs after all other IR level optimization. These other optimization passes keep the branch frequency info (BFI) metadata up to date with CFG and CG changes. The cgprofile pass uses BFI to compute the actual call graph profile. This has to be communicated to the linker somehow, so it gets written to the object file.


https://reviews.llvm.org/D36351





More information about the llvm-commits mailing list