When we load coverage data from multiple objects, we don't have a way to
attribute a source object to a function record. Printing out the object
filename next to the source filename is already not very useful: soon,
it'll actually become misleading. Stop printing out the filename now.
llvm-svn: 285043
Summary:
This is a follow-up to D25416. It removes all usages of TimeValue from
llvm/Support library (except for the actual TimeValue declaration), and replaces
them with appropriate usages of std::chrono. To facilitate this, I have added
small utility functions for converting time points and durations into appropriate
OS-specific types (FILETIME, struct timespec, ...).
Reviewers: zturner, mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25730
llvm-svn: 284966
Initializing a ThreadPool with ThreadCount = 1 spawns a thread even
though we don't need to. This is at least slower than it needs to be,
and at worst may somehow be exacerbating PR30735 (llvm-cov times out
on ARM bots).
As a follow-up, I'll try to add logic to llvm::ThreadPool to avoid
spawning a thread when ThreadCount = 1.
llvm-svn: 284621
The core of the change is supposed to be NFC, however it also fixes
what I believe was an undefined behavior when calling:
va_start(ValueArgs, Desc);
with Desc being a StringRef.
Differential Revision: https://reviews.llvm.org/D25342
llvm-svn: 283671
... so that they don't show up in the index. This came up because polly
contains a .git directory and some other unmapped input in its source
dir.
llvm-svn: 282282
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
We've supported restricting coverage reports to a set of files for a
long time. Add support for being able to restrict by entire directories.
I suppose this supersedes D20803.
llvm-svn: 282202
Copying in the full text of the function doesn't help at all when we
already know that it's never executed. Just say that it's unexecuted --
the relevant source text has already been printed.
llvm-svn: 281589
llvm-cov writes out an index file in '-output-dir' mode, albeit not a
very informative one. Try to fix that by using the CoverageReport API to
include some basic summary information in the index file.
llvm-svn: 281011
In r279628, we made SourceCoverageView list the binary associated with a
view and started adding labels (e.g "Source: foo" or "Function: bar") to
everything. Condense this information a bit to unclutter reports.
llvm-svn: 280896
The coverage reports contain the source or binary file paths. On Windows,
the file path might contain the seperators of both '/' and '\'. This patch
uses the native path in the coverage reports. For example, on Windows,
all '/' are converted to '\'.
Differential Revision: https://reviews.llvm.org/D23922
llvm-svn: 280061
This patch includes the following changes:
- Included header "Code coverage report" and include the date that the report was created.
- Included title (as specified in a command line option, (i.e llvm-cov -project-title="Simple Test")
- In the summary, list the elf files that the source code file has contributed to.
- Used column heading for "Line No.", "Count No.", Source".
Differential Revision: https://reviews.llvm.org/D23345
llvm-svn: 279628
When using orbis-llvm-cov.exe to generate the HTML report, the HTML report
can look quite different to the source file if it includes tabs.The default
tab size is 2 spaces instead of 8 spaces. A command line switch is
be added to set the tab size.
Differential Revision: https://reviews.llvm.org/D23087
llvm-svn: 277715
This enables users to export coverage information as portable JSON for use by
analysis tools and storage in document based databases.
The export sub-command is invoked just like the others:
llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary
The resulting JSON contains a list of files and functions. Every file object
contains a list of segments, expansions, and a summary of the file's region,
function, and line coverage. Every function object contains the function's name
and regions. There is also a total summary for the entire object file.
Changes since the initial commit (r276813):
- Fixed the regexes in the tests to handle Windows filepaths.
Patch by Eddie Hurtig!
Differential Revision: https://reviews.llvm.org/D22651
llvm-svn: 276818
This enables users to export coverage information as portable JSON for use by
analysis tools and storage in document based databases.
The export sub-command is invoked just like the others:
llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary
The resulting JSON contains a list of files and functions. Every file object
contains a list of segments, expansions, and a summary of the file's region,
function, and line coverage. Every function object contains the function's name
and regions. There is also a total summary for the entire object file.
Patch by Eddie Hurtig!
Differential Revision: https://reviews.llvm.org/D22651
llvm-svn: 276813
Add an option to specify a symbol demangler (as well as options to the
demangler). This can be used to make reports more human-readable.
This option is especially useful in -output-dir mode, since it isn't as
easy to manually pipe reports into a demangler in this mode.
llvm-svn: 275640
Taking a lock before appending to a vector does no good unless threads
reading from the vector also take the lock, because the vector could be
re-sized.
I don't have a good isolated test for this. I found the issue with ASan
while testing a large project. I'm working on a bot that does this.
llvm-svn: 275516
Writing `for (StringRef &SourceFile : ...)` is strange to begin with.
Subsequently capturing "SourceFile" by reference is even stranger. Just
copy the StringRef, since that's cheap to do.
llvm-svn: 275515
It's safe to print out source coverage views using multiple threads when
using the -output-dir mode of the `llvm-cov show` sub-command.
While testing this on my development machine, I observed that the speed
up is roughly linear with the number of available cores. Avg. time for
`llvm-cov show ./llvm-as -show-line-counts-or-regions`:
1 thread: 7.79s user 0.33s system 98% cpu 8.228 total
4 threads: 7.82s user 0.34s system 283% cpu 2.880 total
llvm-svn: 275321
- Add renderView{Header,Footer}, renderLineSuffix, and hasSubViews to
support creating tables with nested views.
- Move the 'Format' cl::opt to make it easier to extend.
- Just create one function view file, instead of overwriting the same
file for every new function. Add a regression test for this.
llvm-svn: 274086
This index lists the reports available in the 'coverage' sub-directory.
This will help navigate coverage output from large projects.
This commit factors the file creation code out of SourceCoverageView and
into CoveragePrinter.
llvm-svn: 274029
Passing -output-dir path/to/dir to llvm-cov show creates path/to/dir if
it doesn't already exist, and prints reports into that directory.
In function view mode, all views are written into
path/to/dir/functions.$EXTENSION. In file view mode, all views are
written into path/to/dir/coverage/$PATH.$EXTENSION.
Changes since the initial commit:
- Avoid accidentally closing stdout twice.
llvm-svn: 273985
This reverts commit r273971. test/profile/instrprof-visibility.cpp is
failing because of an uncaught error in SafelyCloseFileDescriptor.
llvm-svn: 273978
Passing -output-dir path/to/dir to llvm-cov show creates path/to/dir if
it doesn't already exist, and prints reports into that directory.
In function view mode, all views are written into
path/to/dir/functions.$EXTENSION. In file view mode, all views are
written into path/to/dir/coverage/$PATH.$EXTENSION.
llvm-svn: 273971
Vedant Kumar