[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
Friedman, Eli via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 27 15:20:23 PDT 2017
On 6/27/2017 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.
I'm using the default set of targets for now (DLLVM_TARGETS_TO_BUILD not
specified).
> 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@2/llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp.html#L512
Are you sure it's actually rare in practice? I can get roughly 20KB of
data in the name section of an object file just by including
llvm/IR/Module.h (without any other code in the file).
I'll experiment a bit more.
-Eli
>
>
>> On Jun 27, 2017, at 2:40 PM, Friedman, Eli <efriedma at codeaurora.org
>> <mailto: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.
>
> 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 <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
>
--
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/482c6748/attachment-0001.html>
More information about the llvm-dev
mailing list