[Coverage] Use gap regions to select better line exec counts

After clang started emitting deferred regions (r312818), llvm-cov has
had a hard time picking reasonable line execuction counts. There ha

[Coverage] Use gap regions to select better line exec counts

After clang started emitting deferred regions (r312818), llvm-cov has
had a hard time picking reasonable line execuction counts. There have
been one or two generic improvements in this area (e.g r310012), but
line counts can still report coverage for whitespace instead of code
(llvm.org/PR34612).

To fix the problem:

* Introduce a new region kind so that frontends can explicitly label
gap areas.

This is done by changing the encoding of the columnEnd field of
MappingRegion. This doesn't substantially increase binary size, and
makes it easy to maintain backwards-compatibility.

* Don't set the line count to a count from a gap area, unless the count
comes from a wrapped segment.

* Don't highlight gap areas as uncovered.

Fixes llvm.org/PR34612.

llvm-svn: 313597

show more ...

[Coverage] Build sorted and unique segments

A coverage segment contains a starting line and column, an execution
count, and some other metadata. Clients of the coverage library use
segments to prepa

[Coverage] Build sorted and unique segments

A coverage segment contains a starting line and column, an execution
count, and some other metadata. Clients of the coverage library use
segments to prepare line-oriented reports.

Users of the coverage library depend on segments being unique and sorted
in source order. Currently this is not guaranteed (this is why the clang
change which introduced deferred regions was reverted).

This commit documents the "unique and sorted" condition and asserts that
it holds. It also fixes the SegmentBuilder so that it produces correct
output in some edge cases.

Testing: I've added unit tests for some edge cases. I've also checked
that the new SegmentBuilder implementation is fully covered. Apart from
running check-profile and the llvm-cov tests, I've successfully used a
stage1 llvm-cov to prepare a coverage report for an instrumented clang
binary.

Differential Revision: https://reviews.llvm.org/D36813

llvm-svn: 312817

show more ...

[Coverage] Define LineColPair for convenience. NFC.

llvm-svn: 312815

Move two functions to a nicer spot. NFC.

llvm-svn: 309906

Rely on autobrief, remove \briefs from a header. NFC.

llvm-svn: 309905

[Coverage] Add an API to retrive all instantiations of a function (NFC)

The CoverageMapping::getInstantiations() API retrieved all function
records corresponding to functions with more than one inst

[Coverage] Add an API to retrive all instantiations of a function (NFC)

The CoverageMapping::getInstantiations() API retrieved all function
records corresponding to functions with more than one instantiation (e.g
template functions with multiple specializations). However, there was no
simple way to determine *which* function a given record was an
instantiation of. This was an oversight, since it's useful to aggregate
coverage information over all instantiations of a function.

llvm-cov works around this by building a mapping of source locations to
instantiation sets, but this duplicates logic that libCoverage already
has (see FunctionInstantiationSetCollector).

This change adds a new API, CoverageMapping::getInstantiationGroups(),
which returns a list of InstantiationGroups. A group contains records
for each instantiation of some particular function, and also provides
utilities to get the total execution count within the group, the source
location of the common definition, etc.

This lets removes some hacky logic in llvm-cov by reusing
FunctionInstantiationSetCollector and makes the CoverageMapping API
friendlier for other clients.

llvm-svn: 309904

show more ...

[llvm-cov] Allow specifying distinct architectures for each loaded binary

The coverage tool needs to know which slice to look at when it's handed
a universal binary. Some projects need to look at ag

[llvm-cov] Allow specifying distinct architectures for each loaded binary

The coverage tool needs to know which slice to look at when it's handed
a universal binary. Some projects need to look at aggregate coverage
reports for a variety of slices in different binaries: this patch adds
support for these kinds of projects to llvm-cov.

rdar://problem/33579007

llvm-svn: 309747

show more ...

[Coverage] Remove two overloads of CoverageMapping::load. NFC.

These overloads are essentially dead, and pose a maintenance cost
without adding any benefit. This is coming up now because I'd like to

[Coverage] Remove two overloads of CoverageMapping::load. NFC.

These overloads are essentially dead, and pose a maintenance cost
without adding any benefit. This is coming up now because I'd like to
experiment with changing the way we store coverage mapping data, and
would rather not have to fix up the old overloads while doing so.

Testing: check-{llvm,profile}, build clang.
llvm-svn: 306776

show more ...

[Coverage] Improve readability by using a struct. NFC.

llvm-svn: 306340

[ProfileData, Support] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 305969

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

[ProfileData] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 296846

Do a sweep over move ctors and remove those that are identical to the default.

All of these existed because MSVC 2013 was unable to synthesize default
move ctors. We recently dropped support for it

Do a sweep over move ctors and remove those that are identical to the default.

All of these existed because MSVC 2013 was unable to synthesize default
move ctors. We recently dropped support for it so all that error-prone
boilerplate can go.

No functionality change intended.

llvm-svn: 284721

show more ...

[Coverage] Support loading multiple binaries into a CoverageMapping

Add support for loading multiple coverage readers into a single
CoverageMapping instance. This should make it easier to prepare a

[Coverage] Support loading multiple binaries into a CoverageMapping

Add support for loading multiple coverage readers into a single
CoverageMapping instance. This should make it easier to prepare a
unified coverage report for multiple binaries.

Differential Revision: https://reviews.llvm.org/D25535

llvm-svn: 284251

show more ...

[Coverage] Delete some copy constructors (NFC)

llvm-svn: 284064

[Coverage] Factor out logic to create FunctionRecords (NFC)

llvm-svn: 284063

[Coverage] Clarify a function contract (NFC)

llvm-svn: 282287

[Coverage] Delete some dead code (NFC)

llvm-svn: 280956

[Coverage] Make sorting criteria for CounterMappingRegions local.

Move the comparison function into the only place there it is used,
i.e. the call to std::stable_sort in CoverageMappingWriter::write

[Coverage] Make sorting criteria for CounterMappingRegions local.

Move the comparison function into the only place there it is used,
i.e. the call to std::stable_sort in CoverageMappingWriter::write().

Add sorting by region kinds as it is required to ensure stable order
in our tests and to simplify D23987.

Differential Revision: https://reviews.llvm.org/D24034

llvm-svn: 280198

show more ...

[Coverage] Mark more methods const (NFC)

llvm-svn: 276474

[Coverage] Mark a few more methods const (NFC)

llvm-svn: 275514

[Coverage] Return an ArrayRef to avoid copies (NFC)

llvm-svn: 275338

[Coverage] Mark a few methods const (NFC)

llvm-svn: 275337

Retry^3 "[ProfileData] (llvm) Use Error in InstrProf and Coverage, NFC"

Transition InstrProf and Coverage over to the stricter Error/Expected
interface.

Changes since the initial commit:
- Fix erro

Retry^3 "[ProfileData] (llvm) Use Error in InstrProf and Coverage, NFC"

Transition InstrProf and Coverage over to the stricter Error/Expected
interface.

Changes since the initial commit:
- Fix error message printing in llvm-profdata.
- Check errors in loadTestingFormat() + annotateAllFunctions().
- Defer error handling in InstrProfIterator to InstrProfReader.
- Remove the base ProfError class to work around an MSVC ICE.

Differential Revision: http://reviews.llvm.org/D19901

llvm-svn: 270020

show more ...

Revert "Retry^2 "[ProfileData] (llvm) Use Error in InstrProf and Coverage, NFC""

This reverts commit r269694. MSVC says:

error C2086: 'char llvm::ProfErrorInfoBase<enum llvm::instrprof_error>::ID'

Revert "Retry^2 "[ProfileData] (llvm) Use Error in InstrProf and Coverage, NFC""

This reverts commit r269694. MSVC says:

error C2086: 'char llvm::ProfErrorInfoBase<enum llvm::instrprof_error>::ID' : redefinition

llvm-svn: 269700

show more ...