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

[Friedman, Eli via llvm-dev]

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>

-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 
> <mailto:davidxl at google.com>> wrote:
>
>
>
>     On Tue, Jun 27, 2017 at 2:09 PM, Friedman, Eli
>     <efriedma at codeaurora.org <mailto: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 <mailto: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 <http://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/b11e2973/attachment.html>