[llvm] Fix bugprone argument comments (NFC)

Identified with bugprone-argument-comment.

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

[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

[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

show more ...

[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, s

[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::thread::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

show more ...

Revert "[llvm-cov] Add option to whitelist filenames"

This reverts commit bfed824b57d14e2ba98ddbaf1a1410cf04a3e279, the
included test fails on many bots including the sanitier bots, e.g. in
http://l

Revert "[llvm-cov] Add option to whitelist filenames"

This reverts commit bfed824b57d14e2ba98ddbaf1a1410cf04a3e279, 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

show more ...

[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://

[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

show more ...

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

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

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

show more ...

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

[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

[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

show more ...

[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

[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

show more ...

Remove redundant includes from tools.

llvm-svn: 320631

[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

[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

show more ...

[llvm-cov] Hide files with no coverage from the index when filtering by name

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

llvm-svn: 314782

[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 (fu

[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

show more ...

Revert "[llvm-cov] Create directory structure when filtering using -name*= options"

Test failures.

llvm-svn: 314314

[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 (fu

[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

show more ...

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

[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

show more ...

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

[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

show more ...

[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 "NotCover

[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

show more ...

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

[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

show more ...

[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

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

[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

show more ...

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