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