[llvm-dev] [RFC] Placing profile name data, and coverage data, outside of object files
Friedman, Eli via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 3 11:44:19 PDT 2017
On 7/3/2017 11:19 AM, Mehdi AMINI via llvm-dev wrote:
> 2017-06-30 22:04 GMT-07:00 Sean Silva via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>:
> On Fri, Jun 30, 2017 at 5:54 PM, via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Instrumentation for PGO and frontend-based coverage places a
> large amount of
> data in object files, even though the majority of this data is
> not needed at
> run-time. All the data is needlessly duplicated while
> generating archives, and
> again while linking. PGO name data is written out into raw
> profiles by
> instrumented programs, slowing down the training and code
> coverage workflows.
> Here are some numbers from a coverage + RA build of ToT clang:
> * Size of the build directory: 4.3 GB
> * Wall time needed to run "clang -help" with an SSD: 0.5 seconds
> * Size of the clang binary: 725.24 MB
> * Space wasted on duplicate name/coverage data (*.o + *.a):
> 923.49 MB
> - Size contributed by __llvm_covmap sections: 1.02 GB
> \_ Just within clang: 340.48 MB
> We live with this duplication for debug info. In some sense, if
> the overhead is small compared to debug info, should we even
> bother (i.e., we assume that users accommodate debug builds, so
> that is a reasonable bound on the tolerable build directory size).
> (I don't know the numbers; this seems pretty large so maybe it is
> significant compared to debug info; just saying that looking at
> absolute numbers is misleading here; numbers compared to debug
> info are a closer measure to the user's perceptions)
> From a build directory point of view, I agree. However when deploying
> on embedded device with "limited" space/memory you can strip the debug
> info and keep them locally because they're not needed on the device
> for running (or remote-debugging), is it the case with the profile infos?
__llvm_prf_names and __llvm_prf_data can't be stripped at the moment:
in-process profile writing code copies them into the profile file.
Changing that is part of this proposal (but it could be fixed with a
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev