<div dir="ltr"><br><span><div dir="ltr" style="margin-left:0pt"></div></span>Yes, "-mllvm -limited-coverage-experimental=true" did help us with Chromium. Things still are crazy large, but smaller than before.<div><br></div><div>Also, make sure to use "-sparse" option of <span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">llvm-profdata<span> tool. It doesn't emit function records with 0 execution count.</span></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><br></span></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span>For instance, when generating code coverage for Chromium, we generate 37 GB of .profraw files (1000+ dumps from ~370 binaries), but the resulting .profdata is only ~605 MB. If we merge it without -sparse, it becomes ~878 MB.</span></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 10, 2018 at 9:57 PM Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">I should have mentioned that there is a bug report about the scaling issue:<div><a href="https://bugs.llvm.org/show_bug.cgi?id=34533" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=34533</a></div><div><br></div><div>One promising solution is to give the empty coverage mappings names, mark them as linkonce_odr, and store them into a different section. The premise of this approach is that clang will emit identical empty mappings for a function many times, say, if it's an inline function in a header. By marking each of these mappings as linkonce_odr, the linker can unique them in the final binary and save a fair amount of space (O(#functions), instead of O(#functions * #translation-units)).</div><div><br></div><div>As I've switched to a different team at work, I don't have the time to work on code coverage bugs at the moment. That said I'd be happy to chat about this further or review patches.</div><div><br></div><div>vedant</div><div><div><br><blockquote type="cite"><div>On May 10, 2018, at 9:39 PM, Vedant Kumar <<a href="mailto:vsk@apple.com" target="_blank">vsk@apple.com</a>> wrote:</div><br class="m_-2924699108277594782Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">+ Max<br><div><br><blockquote type="cite"><div>On May 10, 2018, at 1:25 PM, Harp, Thom via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-2924699108277594782Apple-interchange-newline"><div><div class="m_-2924699108277594782WordSection1" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">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,</span></div></div></div></blockquote><div><br></div><div>Have you tried enabling run-time raw profile merging with "%Nm" (<a href="https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program" target="_blank">https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program</a>)?</div><div><br></div><br><blockquote type="cite"><div><div class="m_-2924699108277594782WordSection1" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt"> built for gcov, totals only 150MB of .gcda files.  I removed emitEmptyMapping from CoverageMapping.cpp to see what happens,</span></div></div></div></blockquote><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div>Er, s/comparable same/comparable/</div><div><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><br><blockquote type="cite"><div><div class="m_-2924699108277594782WordSection1" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt"> 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.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">I don’t mind losing the zero counts for code that is unused</span></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>IMO having some mapping information for unused code is arguably one of the more important use cases for coverage reporting.</div><div><br></div><br><blockquote type="cite"><div><div class="m_-2924699108277594782WordSection1" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif"><span style="font-size:11pt"> but I want to understand how clang determines what’s used and what isn’t.</span></div></div></div></blockquote><div><br></div><span>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:</span></div><div><span><br></span></div><span>- 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.<br></span><span><br></span><span>- 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.</span><div><span><br></span></div><div><span>best,</span></div><div><span>vedant<br></span><span><br><br><blockquote type="cite">  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.<br> <br>Can someone help me understand how clang determines what code is used and what isn’t in this context?<br> <br>Thanks.<br>-thom<br> <br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></blockquote></span><br></div></div></div></blockquote></div><br></div></div></blockquote></div>