[PATCH] D101780: [CoverageMapping] Handle gaps in counter IDs for source-based coverage

Pirama Arumuga Nainar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 11 14:25:56 PDT 2021


pirama added a comment.

In D101780#2752061 <https://reviews.llvm.org/D101780#2752061>, @richkadel wrote:

> @vsk - Also, I want to confirm that it is OK to have counters that are incremented (via `instrprof.increment` intrinsic) that are not associated with a code region.

The expectation is that `No. of code regions > Max. counter ID`.  If there are no gaps in counter IDs, and counters IDs start at 0, then `Max. counter ID = No. of counters - 1`, so we'd need `No. of code regions >= No. of counters`.

The underlying reasoning is that for line coverage, we can assign one counter per code region and so we'd need any more counters than regions.

> Without a code region, I can't add that counter to the coverage map, so, assuming this is not violating LLVM's assumptions, I guess there may be counter ID gaps.
>
> I'm not sure what clang or swiftc does, but in the Rust FE, I sometimes need to count edges between nodes in the CFG (branches taken, between two blocks) since the target block can be executed from multiple incoming edges.

Do we need counters on edges if we're only interested in line segment coverage?

> This seems to work fine so far, but I want to make sure. And my suggested error message (prior comment) is probably not accurate (I now realize).
>
> This stuff is hard to explain :-)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101780



More information about the llvm-commits mailing list