[cfe-dev] SBCC and emitEmptyMapping

Vedant Kumar via cfe-dev cfe-dev at lists.llvm.org
Thu May 10 21:39:07 PDT 2018


+ Max

> On May 10, 2018, at 1:25 PM, Harp, Thom via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Compared to LLVM’s gcov-compatible coverage method, SBCC’s resource requirements are much bigger.  The total size of all .profraw files from my system is almost 1GB while the same system,

Have you tried enabling run-time raw profile merging with "%Nm" (https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program)?


> built for gcov, totals only 150MB of .gcda files.  I removed emitEmptyMapping from CoverageMapping.cpp to see what happens,

Some engineers working on Chromium tried something similar using an experimental cl::opt (-limited-coverage-experimental) which may have a comparable same effect. I've CC'd Max who may be able to say more about this.


> and the SBCC coverage dumps dropped from 1GB to about 26MB.  There are also significant gains in runtime memory use and on-disk image size.
>  
> I don’t mind losing the zero counts for code that is unused

In this case, I'd suggest trying the cl::opt I mentioned above, with the caveat that it can skew coverage reporting quite a bit.

IMO having some mapping information for unused code is arguably one of the more important use cases for coverage reporting.


> but I want to understand how clang determines what’s used and what isn’t.

See AddDeferredUnusedCoverageMapping, ClearUnusedCoverageMapping, and EmitDeferredUnusedCoverageMappings. I'm not the original author so I might not have this totally right, but I think the idea here is that:

- In CodeGenModule::EmitTopLevelDecl, we might not be sure a Decl actually needs to be emitted, so we mark it as deferred for coverage reporting purposes. If we never generate code for it, we'd emit a simple empty coverage mapping.

- If it turns out that a Decl marked as deferred is actually emitted, we clear the deferred bit, because we no longer want an empty mapping.

best,
vedant


>   I traced the decision up to CodeGenPGO::assignRegionCounters in CodeGenPGO.cpp, where implicit functions and some constructor/destructor variants are eliminated but I can’t explain the bulk of it.
>  
> Can someone help me understand how clang determines what code is used and what isn’t in this context?
>  
> Thanks.
> -thom
>  
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180510/665a3e4d/attachment.html>


More information about the cfe-dev mailing list