History log of /llvm-project/llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h (Results 51 – 75 of 106)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4
# 772e1dd1 23-Mar-2021 Choongwoo Han <choongwoo.han@microsoft.com>

[Coverage] Load records immediately

The current implementation keeps buffers generated for each object file
until it completes loading of all files. This approach requires a lot of memory
if there a

[Coverage] Load records immediately

The current implementation keeps buffers generated for each object file
until it completes loading of all files. This approach requires a lot of memory
if there are a lot of huge object files. Thus, make it to load coverage records
immediately rather than waiting for other binaries to be loaded.

This reduces memory usage of llvm-cov from >128GB to 5GB when
loading Chromium binaries in Windows.

Additional testing: check-profile, check-llvm

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

show more ...


Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2
# 5fbd1a33 10-Feb-2021 Petr Hosek <phosek@google.com>

[Coverage] Store compilation dir separately in coverage mapping

We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for dis

[Coverage] Store compilation dir separately in coverage mapping

We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for distributed
compilation as source location might vary across machines. We are also
duplicating the path prefix potentially wasting space.

This change modifies how we store filenames in coverage mapping. Rather
than absolute paths, it stores the compilation directory and file paths
as given to the compiler, either relative or absolute. Later when
reading the coverage mapping information, we recombine relative paths
with the working directory. This approach is similar to handling
ofDW_AT_comp_dir in DWARF.

Finally, we also provide a new option, -fprofile-compilation-dir akin
to -fdebug-compilation-dir which can be used to manually override the
compilation directory which is useful in distributed compilation cases.

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

show more ...


# fbf8b957 18-Feb-2021 Petr Hosek <phosek@google.com>

Revert "[Coverage] Store compilation dir separately in coverage mapping"

This reverts commit 97ec8fa5bb07e3f5bf25ddcb216b545cd3d03b65 since
the test is failing on some bots.


# 97ec8fa5 10-Feb-2021 Petr Hosek <phosek@google.com>

[Coverage] Store compilation dir separately in coverage mapping

We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for dis

[Coverage] Store compilation dir separately in coverage mapping

We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for distributed
compilation as source location might vary across machines. We are also
duplicating the path prefix potentially wasting space.

This change modifies how we store filenames in coverage mapping. Rather
than absolute paths, it stores the compilation directory and file paths
as given to the compiler, either relative or absolute. Later when
reading the coverage mapping information, we recombine relative paths
with the working directory. This approach is similar to handling
ofDW_AT_comp_dir in DWARF.

Finally, we also provide a new option, -fprofile-compilation-dir akin
to -fdebug-compilation-dir which can be used to manually override the
compilation directory which is useful in distributed compilation cases.

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

show more ...


Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1
# 9f2967bc 28-Dec-2020 Alan Phipps <a-phipps@ti.com>

[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage

This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating

[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage

This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating conditions are taken (evaluate to TRUE)
and not taken (evaluate to FALSE). Individual conditions may comprise larger
boolean expressions using boolean logical operators. This functionality is
very similar to what is supported by GCOV except that it is very closely
anchored to the ASTs.

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

show more ...


Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1
# 7fafaa07 13-Oct-2020 Vedant Kumar <vsk@apple.com>

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary (reland)

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slice

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary (reland)

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.

(This version of the patch avoids using llvm::none_of -- the way I used
the utility caused compile errors on many bots, possibly because the
wrong overload of `none_of` was selected.)

rdar://40312677

show more ...


# 10b6d090 13-Oct-2020 Vedant Kumar <vsk@apple.com>

Revert "[llvm-cov] Warn when -arch spec is missing/invalid for universal binary"

This reverts commit b81d4bfb44c14575130bb06c047728b69c3213aa.

It's causing some bots to fail to build due to: "error

Revert "[llvm-cov] Warn when -arch spec is missing/invalid for universal binary"

This reverts commit b81d4bfb44c14575130bb06c047728b69c3213aa.

It's causing some bots to fail to build due to: "error: no matching
function for call to ‘__iterator_category".

show more ...


# b81d4bfb 13-Oct-2020 Vedant Kumar <vsk@apple.com>

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make t

[llvm-cov] Warn when -arch spec is missing/invalid for universal binary

llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.

rdar://40312677

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1
# d7f1eafd 10-May-2020 Simon Pilgrim <llvm-dev@redking.me.uk>

CoverageMapping.h - remove unused StringSet.h include. NFC.


Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3
# e63a3b44 29-Feb-2020 Vedant Kumar <vsk@apple.com>

Add cast to appease clang-armv7-linux-build-cache (D69471 followup)

http://lab.llvm.org:8011/builders/clang-armv7-linux-build-cache/builds/27075

error: non-constant-expression cannot be narrowed fr

Add cast to appease clang-armv7-linux-build-cache (D69471 followup)

http://lab.llvm.org:8011/builders/clang-armv7-linux-build-cache/builds/27075

error: non-constant-expression cannot be narrowed from type 'uint64_t'
(aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in
initializer list [-Wc++11-narrowing]
return {MappingBuf, getDataSize<FuncRecordTy, Endian>(Record)};

show more ...


Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# dd1ea9de 21-Oct-2019 Vedant Kumar <vsk@apple.com>

Reland: [Coverage] Revise format to reduce binary size

Try again with an up-to-date version of D69471 (99317124 was a stale
revision).

---

Revise the coverage mapping format to reduce binary size

Reland: [Coverage] Revise format to reduce binary size

Try again with an up-to-date version of D69471 (99317124 was a stale
revision).

---

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


# 33888717 29-Feb-2020 Vedant Kumar <vsk@apple.com>

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit 99317124e1c772e9a9de41a0cd56e1db049b4ea4. This is
still busted on Windows:

http://lab.llvm.org:8011/builders/lld-x86_64-w

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit 99317124e1c772e9a9de41a0cd56e1db049b4ea4. This is
still busted on Windows:

http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/40873

The llvm-cov tests report 'error: Could not load coverage information'.

show more ...


# 99317124 21-Oct-2019 Vedant Kumar <vsk@apple.com>

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


# f208b70f 04-Dec-2019 Vedant Kumar <vsk@apple.com>

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc.

On Windows, there is an error:

http://lab.llvm.org:8011/builders/sanitizer-win

Revert "[Coverage] Revise format to reduce binary size"

This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc.

On Windows, there is an error:

http://lab.llvm.org:8011/builders/sanitizer-windows/builds/54963/steps/stage%201%20check/logs/stdio

error: C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\profile\Profile-x86_64\Output\instrprof-merging.cpp.tmp.v1.o: Failed to load coverage: Malformed coverage data

show more ...


# e1853159 21-Oct-2019 Vedant Kumar <vsk@apple.com>

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


# 72670a79 02-Nov-2019 Simon Pilgrim <llvm-dev@redking.me.uk>

llvm.coverage.FunctionRecord - fix uninitialized variable warning. NFCI.


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6
# 413647d7 16-Sep-2019 Vedant Kumar <vsk@apple.com>

[Coverage] Speed up file-based queries for coverage info, NFC

Speed up queries for coverage info in a file by reducing the amount of
time spent determining whether a function record corresponds to a

[Coverage] Speed up file-based queries for coverage info, NFC

Speed up queries for coverage info in a file by reducing the amount of
time spent determining whether a function record corresponds to a file.

This gives a 36% speedup when generating a coverage report for `llc`.
The reduction is entirely in user time.

rdar://54758110

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

llvm-svn: 372025

show more ...


Revision tags: llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# f025968b 28-Aug-2019 James Y Knight <jyknight@google.com>

Ignore object files that lack coverage information.

Before this change, if multiple binary files were presented, all of them must have been instrumented or the load would fail with coverage_map_erro

Ignore object files that lack coverage information.

Before this change, if multiple binary files were presented, all of them must have been instrumented or the load would fail with coverage_map_error::no_data_found.

Patch by Dean Sturtevant.

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

llvm-svn: 370257

show more ...


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@gmail.com>

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


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1
# 05090708 29-Sep-2018 Vitaly Buka <vitalybuka@google.com>

[cxx2a] Fix warning triggered by r343285

llvm-svn: 343369


Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2
# e302fc59 07-Aug-2018 Vedant Kumar <vsk@apple.com>

[Coverage] Delete getCounterMismatches, it's dead code (NFC)

Exactly one counted region is inserted into a function record for every
region in a coverage mapping.

llvm-svn: 339193


Revision tags: llvmorg-7.0.0-rc1
# f78650a8 30-Jul-2018 Fangrui Song <maskray@google.com>

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338293


Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2
# 0c5b6020 08-May-2018 Max Moroz <mmoroz@chromium.org>

[Coverage] Take filenames into account when loading function records.

Summary:
Don't skip functions with the same name but from different files.

That change makes it possible to generate code cover

[Coverage] Take filenames into account when loading function records.

Summary:
Don't skip functions with the same name but from different files.

That change makes it possible to generate code coverage reports from
different binaries compiled from different sources even if there are functions
with non-unique names. Without that change, code coverage for such functions is
missing except of the first function processed.

Reviewers: vsk, morehouse

Reviewed By: vsk

Subscribers: llvm-commits, kcc

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

llvm-svn: 331801

show more ...


Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1
# 821160d5 18-Oct-2017 Vedant Kumar <vsk@apple.com>

[llvm-cov] Move LineCoverageIterator to libCoverage. NFC.

LineCoverageIterator makes it easy for clients of coverage data to
determine line execution counts for a file or function. The coverage
iter

[llvm-cov] Move LineCoverageIterator to libCoverage. NFC.

LineCoverageIterator makes it easy for clients of coverage data to
determine line execution counts for a file or function. The coverage
iteration logic is tricky enough that it really pays not to have
multiple copies of it. Hopefully having just one implementation in LLVM
will make the iteration logic easier to test, reuse, and update.

This commit is NFC but I've added a unit test to go along with it just
because it's easy to do now.

llvm-svn: 316141

show more ...


# 18dd9e88 21-Sep-2017 Vedant Kumar <vsk@apple.com>

[llvm-cov] Improve error messaging for function mismatches

Passing "-dump" to llvm-cov will now print more detailed information
about function hash and counter mismatches. This should make it easier

[llvm-cov] Improve error messaging for function mismatches

Passing "-dump" to llvm-cov will now print more detailed information
about function hash and counter mismatches. This should make it easier
to debug *.profdata files which contain incorrect records, and to debug
other scenarios where coverage goes missing due to mismatch issues.

llvm-svn: 313853

show more ...


12345