[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage

Tue Jun 27 14:48:50 PDT 2017

On Tue, Jun 27, 2017 at 2:41 PM, <vsk at apple.com> wrote:

> With llc, the size of the names section can vary widely depending on the
> value of -DLLVM_TARGETS_TO_BUILD.
>
>
Sure.

> Enabling coverage shouldn't increase the name section size much. I only
> see one place where this happens, and it's relatively cold:
> http://lab.llvm.org:8080/coverage/coverage-reports/llvm/coverage/Users/
> buildslave/jenkins/sharedspace/clang-stage2-coverage-R at 2/llvm/lib/
> Transforms/Instrumentation/InstrProfiling.cpp.html#L512
>
>

What is the data set used to create the coverage data there?  Looks like
the lower Coverage function is called 6 times (aka only 6 modules have
coverage data) and on average, each coverage data only references ~2
names.  This does not seem typical.

>
> On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org>
> wrote:
>
> I get a bunch of unreadable binary.  Output piped to "less":
>
> String dump of section '__llvm_prf_names':
>   [     2]  #<CA>^Ex<DA><D4>is<E3>(^Z<EF>^O<DD>^P<A9><D5><F7><9B><CB><
> FB><A8>d<97>^U<96>O<9F><89><FB><85>AQ<B4>M<B5><B6>&)Wy~<
> FD>C^B\<B0>/$<A5><EA>s<E3><CE>L<97>E$^R<89>Dn<C8>L<84><FF>
> <EF><C7>h<B7><FB><DC>ߊ,=<BC><BF>$ow~<B0>\<C4><FF>_X<FE><E0>
> <C7><D1>&<C9>c<F4><E7>^_<AB><B0><F9>,`<BE>H^Oi1G<BF>{<E3><
> D7>({O<8A><E7>S<91>^^^O<B9>7<BB><CD><F7><F3>C^d<E7>}r("<F8>c^P P<83>
> <D0><F3>`T^Z<ED><D2><FF>M<B2><F9>k^X^D/<8B><D5>8<A4><E1>N><
> A3><DD>9<C9><E7><DF><F1><F7>c^B38<9C><F7>^<BF><C2>ߕ^_<D6><
> F0>_<F2><BB>]<94><E7><C1><FD><E9><95>^A3<<9E>^\<B0>{\^O0<CC>
> <C9>)<CA>r<84><D9>j^H<B3><DC><F9><F3><EF><B7><FE>
> <8C><E1>'L^Q<C9>"<F0><A7>"><E8><FF><DD>^^V^R<A4><D6><FC>d<
> EB>j*oHO<D5>^F<C2>p<D0>^U<82><EF>^Y!<90><9D>O5;:^TgL<F9>^Y<
> D3>z<D5>#=<81><E1><C3>6<C4>^\u%<85>7<EE>^Jaf^D0C<8B><8C>r^
> D^E<9D><B5>^W^L<A3>dx<FA><A3>1<FE><88>l^OO<AB>^Z<80>^\~^I<
> EE><DE>^O>]V~c<C9>^D<B7><88>[4|0^R<89><B5>ʳ<96><D7>Ӽ<E7><
> F9>^D<EB>^<BF><A5><9B>Mr^Ht<CC>A^PP<EF>
> <8D>n<BA><89>q<91><DE>
>
>
> This looks compressed to me.
>
>
Yes.

David

> vedant
>
>
>
> -Eli
>
> On 6/27/2017 2:32 PM, Xinliang David Li wrote:
>
> I had an old build of llc with FE instrumentation, the name section size
> is about 5MB.  Using coverage is likely to cause the name section to be
> larger as there are more references to dead/unused function names.
>
> What do you see when
>
> readelf --string-dump=__llvm_prf_names llc
>
> David
>
> On Tue, Jun 27, 2017 at 2:23 PM, Xinliang David Li <davidxl at google.com>
> wrote:
>
>>
>>
>> On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli <efriedma at codeaurora.org>
>> wrote:
>>
>>> On 6/27/2017 1:47 PM, Xinliang David Li wrote:
>>>
>>>
>>>
>>> On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli <efriedma at codeaurora.org>
>>> wrote:
>>>
>>>> On 6/19/2017 7:29 PM, Vedant Kumar wrote:
>>>>
>>>>
>>>> We can reduce testing time by *not* instrumented basic tools like
>>>> count, not, FileCheck etc. I filed: llvm.org/PR33501.
>>>>
>>>> 3. The generated profile information takes up a lot of space: llc
>>>> generates a 90MB profraw file.
>>>>
>>>>
>>>> I don't have any ideas about how to fix this. You can decrease the
>>>> space overhead for raw profiles by altering LLVM_PROFILE_MERGE_POOL_SIZE
>>>> from 4 to a lower value.
>>>>
>>>>
>>>> Disk space is cheap, but the I/O takes a long time.  I guess it's
>>>> specifically bad for LLVM's "make check", maybe not so bad for other cases.
>>>>
>>>>
>>>> You can speed up "make check" a bit by using non-instrumented versions
>>>> of count, not, FileCheck, etc.
>>>>
>>>>
>>>> I tried looking into this a bit more.  It looks like the profile data
>>>> file generated by llc contains approximately 5MB of counters
>>>> (__llvm_prf_cnts), 10MB of "data" (__llvm_prf_data), and 70MB of
>>>> __llvm_prf_names.  __llvm_prf_data and __llvm_prf_names contain which can
>>>> be read from the original binary, as far as I can tell.  The 80MB of data
>>>> wouldn't be a big deal if it were just sitting on disk... but we also erase
>>>> the whole file and rewrite it from scratch after we merge profile counters.
>>>>
>>>>
>>> Can you check if name compression is turned on in your build?
>>>
>>> David
>>>
>>>
>>> I think it is. At least, I didn't intentionally turn it off, and
>>> examining the file with objdump I don't see any uncompressed strings.  Not
>>> sure if there's any easy way to confirm that.
>>>
>>
>>
>> Just a little surprised at the size of __llvm_prf_names section. The llc
>> I built with IR PGO has a __llvm_prf_names section with size  ~1.4MB.    I
>> expect FE instrumentation to produce larger name section size, but not so
>> much bigger.
>>
>> David
>>
>>>
>>> -Eli
>>>
>>> --
>>> Employee of Qualcomm Innovation Center, Inc.
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>>>
>>>
>>
>
> --
> 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/20170627/f4c77191/attachment.html>