llvm dev - Jun 2017 - My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage

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 we do better here?

-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/20170626/6ad7cce6/attachment.html>

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 we do better here?
>
yes, something can be done there. I will look into it.

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/20170626/0d9073e5/attachment.html>

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


Can we do better here?
>
> -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/4b82f147/attachment.html>

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>