<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 7/3/2017 11:19 AM, Mehdi AMINI via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANF-O=a5DitD2i85y68coiN4OdHspSDh5BX0wG1tc7ub=j-bPA@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-06-30 22:04 GMT-07:00 Sean Silva
via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Fri, Jun
30, 2017 at 5:54 PM, via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Problem<br>
-------<br>
<br>
Instrumentation for PGO and frontend-based
coverage places a large amount of<br>
data in object files, even though the majority
of this data is not needed at<br>
run-time. All the data is needlessly duplicated
while generating archives, and<br>
again while linking. PGO name data is written
out into raw profiles by<br>
instrumented programs, slowing down the training
and code coverage workflows.<br>
<br>
Here are some numbers from a coverage + RA build
of ToT clang:<br>
<br>
* Size of the build directory: 4.3 GB<br>
<br>
* Wall time needed to run "clang -help" with
an SSD: 0.5 seconds<br>
<br>
* Size of the clang binary: 725.24 MB<br>
<br>
* Space wasted on duplicate name/coverage data
(*.o + *.a): 923.49 MB<br>
- Size contributed by __llvm_covmap
sections: 1.02 GB<br>
\_ Just within clang: 340.48 MB<br>
</blockquote>
<div><br>
</div>
</span>
<div>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)</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</div>
</blockquote>
<br>
__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).<br>
<br>
-Eli<br>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>