[PATCH] D116180: [InstrProf] Add single byte coverage mode

[Ellis Hoag via Phabricator via llvm-commits]

ellis added a comment.

In D116180#3211818 <https://reviews.llvm.org/D116180#3211818>, @kyulee wrote:

> In the high-level discussion, this is really a function coverage because it probes the function header, but the flag or terminology inter-mixed just a coverage.

You're right, I should update the flag name to make it more clear that this is only a function entry coverage.

> For the code (not just function) coverage, I think we might want to have an option to inject this probe in the block edge as well so that the default/code-coverage can be fully functional. 
> Of course, this could be a follow-up, but just head-up on how this can be factored in this design.

I've experimented with instrumenting clang with block coverage vs block counts. It turns out that full block coverage actually requires a larger counters section than regular block counts. This is because, for block counts, we can infer some missing block counts from summing up their parents or children. However, we cannot do this when using boolean values in the same way. So every basic block must be probed. (There are some cases where you can infer some missing block coverage, but I haven't thought deeply about when you can do this. And I suspect this is rare.) Also, there was slightly less assembly code from block counts rather than block coverage, but that only made the overall size difference negligible between the two.

Basically, block coverage has about the same size overhead, but gives significantly less information than block counts. We could allow for counters to be 16 or 8 bits to save space in the block counters mode, but that would be left for a later diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116180