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

[Xinliang David Li via llvm-dev]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/6eb1ea1c/attachment.html>