[PATCH] D124490: [InstrProf] Minimal Block Coverage

[Ellis Hoag via Phabricator via llvm-commits]

ellis added a comment.

In D124490#3526752 <https://reviews.llvm.org/D124490#3526752>, @gulfem wrote:

> `CoverageMappingGen.cpp` adds counters while traversing AST. For ex, this is how counters are added for an if statement.
> https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CoverageMappingGen.cpp#L1383
> I'm currently building the prototype for using boolean counters in coverage, and I'm planning to upload a WIP review soon.
> After that, we can discuss further whether BlockCoverageInference can be generalized.
>
> In D124490#3522697 <https://reviews.llvm.org/D124490#3522697>, @ellis wrote:
>
>> I'm also wondering if we could use this `PGO` coverage to infer source-based code coverage by looking at debug info.
>
> How are you planning to use `block coverage` for `PGO`?
> In some of the tools that we show source-based coverage, we show whether a line is covered by the executed tests and do not show how many times each line is executed. For this specific purpose, we want to use single byte counters.
> Although I'm not that familiar with `PGO` implementation, it seems like number counters might be more beneficial for making optimization decisions for `PGO`.  Are there specific optimizations that you are planning to use `block coverage`?

The default PGO instruments counters and is useful for optimization. That problem is that this instrumentation is expensive with respect to binary size and runtime. This diff adds a block coverage mode which is much smaller and faster, although the data is not as precise. In the parent diff D125743 <https://reviews.llvm.org/D125743> I've added support to use block coverage to outline blocks that are not covered and we may use this data to guide more optimizations in the future.

About the source-based coverage, my intuition is that adding coverage instrumentation to clang AST is less efficient than adding coverage instrumentation to blocks in the LLVM-IR like this diff does. In theory, I think it's possible to map covered LLVM-IR blocks to source code using debug info. Then you would only need to run this block instrumentation and get source coverage out of the profiles. Unfortunately, we don't maintain the binary address or source locations of instrumented blocks in our profiles, so this idea would require some format changes. I'm just throwing out ideas and I'm now realizing https://discourse.llvm.org/ would be a good place for this discussion. Feel free to reach out there if you'd like to talk about it more.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124490/new/

https://reviews.llvm.org/D124490