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

[Xinliang David Li via llvm-dev]

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>