[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 14:40:18 PDT 2017
I get a bunch of unreadable binary. Output piped to "less":
String dump of section '__llvm_prf_names':
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
> 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?
> 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.
> 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...
More information about the llvm-dev