[Coverage] Revise format to reduce binary size

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

[Coverage] Revise format to reduce binary size

Revise the coverage mapping format to reduce binary size by:

1. Naming function records and marking them `linkonce_odr`, and
2. Compressing filenames.

This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB)
and speeds up end-to-end single-threaded report generation by 10%. For
reference the compressed name data in llc is 81MB (__llvm_prf_names).

Rationale for changes to the format:

- With the current format, most coverage function records are discarded.
E.g., more than 97% of the records in llc are *duplicate* placeholders
for functions visible-but-not-used in TUs. Placeholders *are* used to
show under-covered functions, but duplicate placeholders waste space.

- We reached general consensus about giving (1) a try at the 2017 code
coverage BoF [1]. The thinking was that using `linkonce_odr` to merge
duplicates is simpler than alternatives like teaching build systems
about a coverage-aware database/module/etc on the side.

- Revising the format is expensive due to the backwards compatibility
requirement, so we might as well compress filenames while we're at it.
This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB).

See CoverageMappingFormat.rst for the details on what exactly has
changed.

Fixes PR34533 [2], hopefully.

[1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html
[2] https://bugs.llvm.org/show_bug.cgi?id=34533

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

show more ...

[Coverage] Assert that filenames in a TU are unique, NFC

llvm-svn: 372024

Use llvm::stable_sort

While touching the code, simplify if feasible.

llvm-svn: 358996

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they ar

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331272

show more ...

[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] Report errors when reading malformed source regions

Each source region has a start and end location. Report an error when
the end location does not precede the begin location.

The old li

[Coverage] Report errors when reading malformed source regions

Each source region has a start and end location. Report an error when
the end location does not precede the begin location.

The old lineExecutionCounts.covmapping test actually had a buggy source
region in it. This commit introduces a regenerated copy of the coverage
and moves the old copy to malformedRegions.covmapping, for a test.

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

llvm-svn: 312814

show more ...

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

[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 ...

Revert "[Coverage] Move logic to encode filenames and mappings into llvm (NFC)"

This reverts commit 520a8298d8ef676b5da617ba3d2c7fa37381e939 (r273055).

This is breaking stage2 instrumented builds w

Revert "[Coverage] Move logic to encode filenames and mappings into llvm (NFC)"

This reverts commit 520a8298d8ef676b5da617ba3d2c7fa37381e939 (r273055).

This is breaking stage2 instrumented builds with "malformed coverage
data" errors.

llvm-svn: 274106

show more ...

[Coverage] Move logic to encode filenames and mappings into llvm (NFC)

Currently, frontends which emit source-based code coverage have to
duplicate logic to encode filenames and raw coverage mapping

[Coverage] Move logic to encode filenames and mappings into llvm (NFC)

Currently, frontends which emit source-based code coverage have to
duplicate logic to encode filenames and raw coverage mappings properly.
This violates an abstraction layer and forces frontends to copy tricky
code.

Introduce llvm::coverage::encodeFilenamesAndRawMappings() to take care
of this.

This will help us experiment with zlib-compressing coverage mapping
data.

llvm-svn: 273055

show more ...

Move coverage related code into a separate library.

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

llvm-svn: 268089