[llvm-dev] [RFC] Placing profile name data, and coverage data, outside of object files

[Friedman, Eli via llvm-dev]

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:
>
>         Problem
>         -------
>
>         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 
narrower change).

-Eli

-- 
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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170703/02ca0bd4/attachment.html>