[llvm-dev] My experience using -DLLVM_BUILD_INSTRUMENTED_COVERAGE to generate coverage
Xinliang David Li via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 27 13:47:31 PDT 2017
On Mon, Jun 26, 2017 at 7:24 PM, Friedman, Eli <efriedma at codeaurora.org>
> 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?
Can we do better here?
> 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