Commit Graph

49 Commits

Author SHA1 Message Date
Kazu Hirata 435a5a3652 [llvm] Fix bugprone argument comments (NFC)
Identified with bugprone-argument-comment.
2022-01-08 11:56:38 -08:00
Alan Phipps 9f2967bcfe [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
2021-01-05 09:51:51 -06:00
Alexandre Ganea 0e13a0331f [llvm-cov] Prevent llvm-cov from using too many threads
As reported here: https://reviews.llvm.org/D75153#1987272

Before, each instance of llvm-cov was creating one thread per hardware core, which wasn't needed probably because the number of inputs were small. This was probably causing a thread rlimit issue on large core count systems.

After this patch, the previous behavior is restored (to what was before rG8404aeb5):

If --num-threads is not specified, we create one thread per input, up to num.cores.
When specified, --num-threads indicates any number of threads, with no upper limit.

Differential Revision: https://reviews.llvm.org/D78408
2020-04-24 15:28:25 -04:00
Alexandre Ganea 8404aeb56a [Support] On Windows, ensure hardware_concurrency() extends to all CPU sockets and all NUMA groups
The goal of this patch is to maximize CPU utilization on multi-socket or high core count systems, so that parallel computations such as LLD/ThinLTO can use all hardware threads in the system. Before this patch, on Windows, a maximum of 64 hardware threads could be used at most, in some cases dispatched only on one CPU socket.

== Background ==
Windows doesn't have a flat cpu_set_t like Linux. Instead, it projects hardware CPUs (or NUMA nodes) to applications through a concept of "processor groups". A "processor" is the smallest unit of execution on a CPU, that is, an hyper-thread if SMT is active; a core otherwise. There's a limit of 32-bit processors on older 32-bit versions of Windows, which later was raised to 64-processors with 64-bit versions of Windows. This limit comes from the affinity mask, which historically is represented by the sizeof(void*). Consequently, the concept of "processor groups" was introduced for dealing with systems with more than 64 hyper-threads.

By default, the Windows OS assigns only one "processor group" to each starting application, in a round-robin manner. If the application wants to use more processors, it needs to programmatically enable it, by assigning threads to other "processor groups". This also means that affinity cannot cross "processor group" boundaries; one can only specify a "preferred" group on start-up, but the application is free to allocate more groups if it wants to.

This creates a peculiar situation, where newer CPUs like the AMD EPYC 7702P (64-cores, 128-hyperthreads) are projected by the OS as two (2) "processor groups". This means that by default, an application can only use half of the cores. This situation could only get worse in the years to come, as dies with more cores will appear on the market.

== The problem ==
The heavyweight_hardware_concurrency() API was introduced so that only *one hardware thread per core* was used. Once that API returns, that original intention is lost, only the number of threads is retained. Consider a situation, on Windows, where the system has 2 CPU sockets, 18 cores each, each core having 2 hyper-threads, for a total of 72 hyper-threads. Both heavyweight_hardware_concurrency() and hardware_concurrency() currently return 36, because on Windows they are simply wrappers over std:🧵:hardware_concurrency() -- which can only return processors from the current "processor group".

== The changes in this patch ==
To solve this situation, we capture (and retain) the initial intention until the point of usage, through a new ThreadPoolStrategy class. The number of threads to use is deferred as late as possible, until the moment where the std::threads are created (ThreadPool in the case of ThinLTO).

When using hardware_concurrency(), setting ThreadCount to 0 now means to use all the possible hardware CPU (SMT) threads. Providing a ThreadCount above to the maximum number of threads will have no effect, the maximum will be used instead.
The heavyweight_hardware_concurrency() is similar to hardware_concurrency(), except that only one thread per hardware *core* will be used.

When LLVM_ENABLE_THREADS is OFF, the threading APIs will always return 1, to ensure any caller loops will be exercised at least once.

Differential Revision: https://reviews.llvm.org/D71775
2020-02-14 10:24:22 -05:00
Vlad Tsyrklevich 8d24d72f7f Revert "[llvm-cov] Add option to whitelist filenames"
This reverts commit bfed824b57, the
included test fails on many bots including the sanitier bots, e.g. in
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/36140
2019-10-29 22:38:38 -07:00
Vedant Kumar bfed824b57 [llvm-cov] Add option to whitelist filenames
Add the `-whitelist-filename-regex` option to restrict coverage
reporting to file paths that match a whitelist regex.

Patch by Michael Daniels!

rdar://56720320
2019-10-29 18:26:33 -07:00
Rui Ueyama 4d41c332ef Revert r367649: Improve raw_ostream so that you can "write" colors using operator<<
This reverts commit r367649 in an attempt to unbreak Windows bots.

llvm-svn: 367658
2019-08-02 07:22:34 +00:00
Rui Ueyama a52f982f1c Improve raw_ostream so that you can "write" colors using operator<<
1. raw_ostream supports ANSI colors so that you can write messages to
the termina with colors. Previously, in order to change and reset
color, you had to call `changeColor` and `resetColor` functions,
respectively.

So, if you print out "error: " in red, for example, you had to do
something like this:

  OS.changeColor(raw_ostream::RED);
  OS << "error: ";
  OS.resetColor();

With this patch, you can write the same code as follows:

  OS << raw_ostream::RED << "error: " << raw_ostream::RESET;

2. Add a boolean flag to raw_ostream so that you can disable colored
output. If you disable colors, changeColor, operator<<(Color),
resetColor and other color-related functions have no effect.

Most LLVM tools automatically prints out messages using colors, and
you can disable it by passing a flag such as `--disable-colors`.
This new flag makes it easy to write code that works that way.

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

llvm-svn: 367649
2019-08-02 04:48:30 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Adrian Prantl 5f8f34e459 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
2018-05-01 15:54:18 +00:00
Max Moroz 4220f89107 [llvm-cov] Implement -ignore-filename-regex= option for excluding source files.
Summary:
The option is helpful for large projects where it's not feasible to specify sources which
user would like to see in the report. Instead, it allows to black-list specific sources via
regular expressions (e.g. now it's possible to skip all files that have "test" in its name).

This also partially fixes https://bugs.llvm.org/show_bug.cgi?id=34277

Reviewers: vsk, morehouse, liaoyuke

Reviewed By: vsk

Subscribers: kcc, mgorny, llvm-commits

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

llvm-svn: 329581
2018-04-09 15:20:35 +00:00
Max Moroz cc254ba4a7 [llvm-cov] Multi-threaded implementation of prepareFileReports method.
Summary:
Local testing has demonstrated a great speed improvement, compare the following:

1) Existing version:
```
$ time llvm-cov show -format=html -output-dir=report -instr-profile=... ...
The tool has been launched:                            00:00:00
Loading coverage data:                                 00:00:00
Get unique source files:                               00:00:33
Creating an index out of the source files:             00:00:34
Going into prepareFileReports:                         00:00:34
Going to emit summary information for each file:       00:28:55 <-- 28:21 min!
Going to emit links to files with no function:         00:28:55
Launching 32 threads for generating HTML files:        00:28:55

real  37m43.651s
user  112m5.540s
sys   7m39.872s
```

2) Multi-threaded version with 32 CPUs:
```
$ time llvm-cov show -format=html -output-dir=report -instr-profile=... ...
The tool has been launched:                            00:00:00
Loading coverage data:                                 00:00:00
Get unique source files:                               00:00:38
Creating an index out of the source files:             00:00:40
Going into prepareFileReports:                         00:00:40
Preparing file reports using 32 threads:               00:00:40
# Creating thread tasks for the following number of files: 16422
Going to emit summary information for each file:       00:01:57 <-- 1:17 min!
Going to emit links to files with no function:         00:01:58
Launching 32 threads for generating HTML files:        00:01:58

real  11m2.044s
user  134m48.124s
sys   7m53.388s
```

Reviewers: vsk, morehouse

Reviewed By: vsk

Subscribers: Dor1s, llvm-commits, kcc

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

llvm-svn: 321871
2018-01-05 16:15:07 +00:00
Michael Zolotukhin 62602a476a Remove redundant includes from tools.
llvm-svn: 320631
2017-12-13 21:31:10 +00:00
Max Moroz 4a4bfa4e27 [llvm-cov] Generate "report" for given source paths if sources are specified.
Summary:
Documentation says that user can specify sources for both "show" and
"report" commands. "Show" command respects specified sources, but "report" does
not. It is useful to have both "show" and "report" generated for specified
sources. Also added tests to for both commands with sources specified.

Reviewers: vsk, kcc

Reviewed By: vsk

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

llvm-svn: 315685
2017-10-13 14:44:51 +00:00
Sean Eveson d932b2d763 [llvm-cov] Hide files with no coverage from the index when filtering by name
Differential Revision: https://reviews.llvm.org/D38457

llvm-svn: 314782
2017-10-03 11:05:28 +00:00
Sean Eveson fa8ef35e78 [llvm-cov] Create directory structure when filtering using -name*= options
Before this change using any of the -name*= command line options with an output
directory would result in a single file (functions.txt/functions.html)
containing the coverage for those specific functions. Now you get the same
directory structure as when not using any -name*= options.

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

llvm-svn: 314396
2017-09-28 10:07:30 +00:00
Sean Eveson 1439fa6236 Revert "[llvm-cov] Create directory structure when filtering using -name*= options"
Test failures.

llvm-svn: 314314
2017-09-27 16:20:07 +00:00
Sean Eveson 51b817479b [llvm-cov] Create directory structure when filtering using -name*= options
Before this change using any of the -name*= command line options with an output
directory would result in a single file (functions.txt/functions.html)
containing the coverage for those specific functions. Now you get the same
directory structure as when not using any -name*= options.

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

llvm-svn: 314310
2017-09-27 15:37:40 +00:00
Vedant Kumar b7fdaf2cd4 [llvm-cov] Make report metrics agree with line exec counts, fixes PR34615
Use the same logic as the line-oriented coverage view to determine the
number of covered lines in a function.

Fixes llvm.org/PR34615.

llvm-svn: 313604
2017-09-19 02:00:12 +00:00
Vedant Kumar c445e65d09 [llvm-cov] Make some summary info fields private. NFC.
There's a bug in the way the line and region summary objects are merged.
It would have been less likely to occur if those objects kept some data
private.

llvm-svn: 313416
2017-09-15 23:00:01 +00:00
Vedant Kumar b84e48447e [llvm-cov] Remove a redundant field. NFC.
The "NotCovered" fields in the region and line summary structs are
redundant. We should remove them to make the code clearer.

As a follow-up, the "NotCovered" entries should be removed from the
reports as well.

llvm-svn: 313415
2017-09-15 23:00:00 +00:00
Eli Friedman 50479f60c4 [llvm-cov] Allow hiding instantiation/region coverage from summary tables
Region coverage is difficult to explain without going deep into how
coverage is implemented. Instantiation coverage is easier to explain,
but probably not useful in most cases (templates don't exist in C, and
most C++ code contains relatively few templates).

This patch adds the options "-show-region-summary" and
"-show-instantiation-summary" to allow hiding those columns.
"-show-instantiation-summary" is turned off by default.

llvm-svn: 312969
2017-09-11 22:56:20 +00:00
Vedant Kumar 72c3a11488 [llvm-cov] Fix a lifetime issue
This fixes an issue where a std::string was moved to a constructor
which accepted a StringRef.

llvm-svn: 312816
2017-09-08 18:44:49 +00:00
Eli Friedman c0c182cce1 [llvm-cov] Rearrange entries in report index.
Files which don't contain any functions are likely useless; don't
include them in the main table. Put the links at the bottom of the
page, in case someone wants to figure out coverage for code inside
a macro.

Not sure if this is the best solution, but it seems like an
improvement.

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

llvm-svn: 310518
2017-08-09 20:43:31 +00:00
Vedant Kumar dde19c5a73 [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
2017-08-02 23:35:25 +00:00
Zachary Turner 368c3fa657 Use the new member accessors of llvm::enumerate.
The value_type is no longer a struct, it's a class whose
members you have to access via a method.

llvm-svn: 297635
2017-03-13 16:32:08 +00:00
Vedant Kumar 1181328071 [llvm-cov] Strip redundant path components from filenames (fix PR31982)
Instead of stripping the longest common prefix off of the filenames in a
report, strip out the longest chain of redundant path components. This
fixes the case in PR31982, where there are two files with the same
prefix, and stripping out the LCP makes things less intelligible.

llvm-svn: 296029
2017-02-23 22:20:32 +00:00
Vedant Kumar f2b067c42e [llvm-cov] Demangle symbols in function summaries (fixes PR31394)
llvm-svn: 294136
2017-02-05 20:11:03 +00:00
Alex Lorenz 35369c1eb6 [llvm-cov] Avoid 0% when reporting something that's 0/0
This commit makes llvm-cov avoid showing 0% (0/0) coverage for things
like file function coverage, etc. in reports and HTML output. This can happen
for files like headers that have macros but no functions. This commit makes
llvm-cov report - (0/0) instead.

rdar://29246480

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

llvm-svn: 287539
2016-11-21 14:00:04 +00:00
Vedant Kumar 5cd496ba3a [llvm-cov] Silence a warning from the MSVC runtime (NFC)
Rework getLongestCommonPrefixLen() so that it doesn't access string null
terminators. The old version with std::mismatch would do this:

                        |
                        v
    Strings[0] = ['a', nil]

    Strings[1] = ['a', 'a', nil]
                        ^
                        |

This should silence a warning from the MSVC runtime (PR30515). As
before, I tested this out by preparing a coverage report for FileCheck.
Thanks to Yaron Keren for the report!

llvm-svn: 282422
2016-09-26 17:57:13 +00:00
Vedant Kumar bc6479850e [llvm-cov] Get rid of all invalid filename references
We used to append filenames into a vector of std::string, and then
append a reference to each string into a separate vector. This made it
easier to work with the getUniqueSourceFiles API. But it's buggy.

std::string has a small-string optimization, so you can't expect to
capture a reference to one if you're copying it into a growing vector.
Add a test that triggers this invalid reference to std::string scenario,
and kill the issue with fire by just using ArrayRef<std::string>
everywhere.

llvm-svn: 282281
2016-09-23 18:57:32 +00:00
Vedant Kumar 9cbf80afc8 [llvm-cov] Make a helper method static for re-use (NFC)
llvm-svn: 281876
2016-09-19 00:38:25 +00:00
Vedant Kumar 016111f7b9 [llvm-cov] Track function and instantiation coverage separately
These are distinct statistics which are useful to look at separately.

Example: say you have a template function "foo" with 5 instantiations
and only 3 of them are covered. Then this contributes (1/1) to the total
function coverage and (3/5) to the total instantiation coverage. I.e,
the old "Function Coverage" column has been renamed to "Instantiation
Coverage", and the new "Function Coverage" aggregates information from
the various instantiations of a function.

One benefit of making this switch is that the Line and Region coverage
columns will start making sense. Let's continue the example and assume
that the 5 instantiations of "foo" cover {2, 4, 6, 8, 10} out of 10
lines respectively. The new line coverage for "foo" is (10/10), not
(30/50).  The old scenario got confusing because we'd report that there
were more lines in a file than what was actually possible.

llvm-svn: 281875
2016-09-19 00:38:23 +00:00
Vedant Kumar dab0ec126e [llvm-cov] Make 'adjustColumnWidths' do less work
This drops some redundant calls to get{UniqueSourceFiles,
CoveredFunctions}. We can figure out the right column widths without
re-doing this expensive work.

This isn't NFC, but I don't want to check in another binary *.covmapping
file with long filenames in it. I tested this locally on a project with
some long filenames (FileCheck).

llvm-svn: 281873
2016-09-19 00:38:16 +00:00
Vedant Kumar d938dfb308 [llvm-cov] Handle native paths correctly in the text index
Treat filenames the same way in the text index as we do in the html
index. This is a follow-up to r281008 (an attempt to unbreak the
native_separators.c test on Windows).

Patch by Maggie Yi!

llvm-svn: 281062
2016-09-09 17:37:11 +00:00
Vedant Kumar 627887b650 [llvm-cov] Add an API to prepare file reports (NFC)
It would be nice to prepare file reports (using the CoverageReport API)
without actually rendering them to the console. I plan on using this to
flesh out the 'index' files in the coverage views.

llvm-svn: 281009
2016-09-09 01:32:49 +00:00
Vedant Kumar fa75437183 [llvm-cov] Drop the longest common filename prefix from summaries
Remove the longest common prefix from filenames when printing coverage
summaries. This makes them easier to compare.

llvm-svn: 280895
2016-09-08 00:56:43 +00:00
Vedant Kumar 5053b11edc [llvm-cov] Use colors consistently in the summary
Use the same color for counts and percentages. There doesn't seem to be
a reason for them to be different, and the summary looks more consistent
this way.

llvm-svn: 280765
2016-09-06 22:46:00 +00:00
Vedant Kumar 702bb9d9b2 [llvm-cov] Clean up the summary class, delete dead code (NFC)
llvm-svn: 280764
2016-09-06 22:45:57 +00:00
Ying Yi e59ee43cf1 [llvm-cov] - Add the coverage of lines in the summary report.
The llvm-cov ‘report' command displays a summary of the coverage of a binary file.
The summary report currently only includes covered regions and covered functions.
This patch adds the coverage of lines in the summary report.

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

llvm-svn: 276409
2016-07-22 12:46:13 +00:00
Vedant Kumar cef440f7a7 [llvm-cov] Avoid copying file paths multiple times (NFC)
llvm-svn: 274027
2016-06-28 16:12:18 +00:00
Vedant Kumar aaead3309a [llvm-cov] Adjust column widths for function and file reports
Previously, we only expanded function and filename column widths when
rendering file reports. This commit makes the change for function
reports as well.

llvm-svn: 250900
2015-10-21 16:03:32 +00:00
Vedant Kumar c3c39e7154 [llvm-cov] Disable name and path truncation
Change the output of llvm-cov s.t it does not truncate function names
and file paths when printing coverage reports.

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

rdar://22531141

llvm-svn: 247635
2015-09-14 23:26:36 +00:00
Justin Bogner 0ef7a2a250 llvm-cov: Actually use the command line arguments when reporting
This code didn't really make sense as is. If a filename is passed in,
the user obviously wants the coverage *for that file*, not *for
everything*.

llvm-svn: 229217
2015-02-14 02:05:05 +00:00
Justin Bogner f91bc6cdd8 llvm-cov: Simplify coverage reports, fixing PR22575 in the process
PR22575 occurred because we were unsafely storing references into a
std::vector. If the vector moved because it grew, we'd be left
iterating through garbage memory. This avoids the issue by simplifying
the logic to gather coverage information as we go, rather than storing
it and iterating over it.

I'm relying on the existing tests showing that this is semantically
NFC, since it's difficult to hit the issue this fixes without
relatively large covered programs.

llvm-svn: 229215
2015-02-14 02:01:24 +00:00
Chandler Carruth d9903888d9 [cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974
2015-01-14 11:23:27 +00:00
NAKAMURA Takumi 46d2e0e53d llvm-cov/CoverageReport.cpp: Quick fix for msvcrt, since width specifier "z" is unavailable.
Note, mingw uses its own printf instead of msvcrt.

llvm-svn: 218723
2014-10-01 00:29:26 +00:00
Alex Lorenz cb1702d45a llvm-cov: Use the number of executed functions for the function coverage metric.
This commit fixes llvm-cov's function coverage metric by using the number of executed functions instead of the number of fully covered functions.

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

llvm-svn: 218672
2014-09-30 12:45:13 +00:00
Alex Lorenz e82d89cc37 llvm-cov: add code coverage tool that's based on coverage mapping format and clang's pgo.
This commit expands llvm-cov's functionality by adding support for a new code coverage
tool that uses LLVM's coverage mapping format and clang's instrumentation based profiling.
The gcov compatible tool can be invoked by supplying the 'gcov' command as the first argument,
or by modifying the tool's name to end with 'gcov'.

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

llvm-svn: 216300
2014-08-22 22:56:03 +00:00