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

[Friedman, Eli via llvm-dev]

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.

-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/108d30ac/attachment.html>