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

[Pirama Arumuga Nainar via Phabricator via llvm-commits]

pirama created this revision.
pirama added a reviewer: vsk.
Herald added subscribers: JDevlieghere, hiraditya.
pirama requested review of this revision.
Herald added a project: LLVM.

For source-based coverage, the frontend sets the counter IDs and the
constraints of counter IDs is not defined.  For e.g., the Rust frontend
until recently had a reserved counter #0
(https://github.com/rust-lang/rust/pull/83774).  The Rust FE does
coverage counter injection before DCE and so there may be more counters
than regions.

The above two aspects break an assumption in CoverageMapping.cpp where
the number of counters in a function is assumed to be bounded by the
number of regions:

  Counts.assign(Record.MappingRegions.size(), 0);

In the Rust scenario, when sparse profiles are used, this assumption
causes CounterMappingContext::evaluate() to fail since there are not
enough counter values created in the above call to `Counts.assign`.
Consequently, some uncovered functions are not reported in coverage
reports.

This change walks a Function's CoverageMappingRecord to find the maximum
counter ID, and uses it to initialize the counter array when instrprof
records are missing for a function in sparse profiles.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101780

Files:
  llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h
  llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
  llvm/unittests/ProfileData/CoverageMappingTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D101780.342506.patch
Type: text/x-patch
Size: 5370 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210503/1704d912/attachment.bin>