Use the llvm flag `-pgo-function-entry-coverage` to create single byte "counters" to track functions coverage. This mode has significantly less size overhead in both code and data because
* We mark a function as "covered" with a store instead of an increment which generally requires fewer assembly instructions
* We use a single byte per function rather than 8 bytes per block
The trade off of course is that this mode only tells you if a function has been covered. This is useful, for example, to detect dead code.
When combined with debug info correlation [0] we are able to create an instrumented Clang binary that is only 150M (the vanilla Clang binary is 143M). That is an overhead of 7M (4.9%) compared to the default instrumentation (without value profiling) which has an overhead of 31M (21.7%).
[0] https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116180
When using debug info for profile correlation, avoid adding duplicate
functions in the synthetic Data section.
Before this patch, n duplicate function entries in the Data section would
cause counter values to be a factor of n larger. I built instrumented
clang with and without debug info correlation and got these summaries.
```
# With Debug Info Correlate
$ llvm-profdata show default.profdata
Instrumentation level: IR entry_first = 0
Total functions: 182530
Maximum function count: 52034
Maximum internal block count: 5763
# Without
$ llvm-profdata show default.profdata
Instrumentation level: IR entry_first = 0
Total functions: 183212
Maximum function count: 52034
Maximum internal block count: 5766
```
The slight difference in counts seem to be mostly from FileSystem and
Map functions and the difference in the number of instrumented functions
seems to come from missing debug info like destructors without source.
Reviewed By: kyulee
Differential Revision: https://reviews.llvm.org/D116051
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32.
To be more consistent everywhere and remove lots of casts from uint64_t
to uint32_t, use i64 for branch_weights.
Reviewed By: davidxl
Differential Revision: https://reviews.llvm.org/D88609
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32.
To be more consistent everywhere and remove lots of casts from uint64_t
to uint32_t, use i64 for branch_weights.
Reviewed By: davidxl
Differential Revision: https://reviews.llvm.org/D88609
For a CFG G=(V,E), Knuth describes that by Kirchoff's circuit law, the minimum
number of counters necessary is |E|-(|V|-1). The emitted edges form a spanning
tree. libgcov emitted .gcda files leverages this optimization while clang
--coverage's doesn't.
Propagate counts by Kirchhoff's circuit law so that llvm-cov gcov can
correctly print line counts of gcc --coverage emitted files and enable
the future improvement of clang --coverage.
GCC r187297 (2012-05) introduced `__gcov_dump` and `__gcov_reset`.
`__gcov_flush = __gcov_dump + __gcov_reset`
The resolution to https://gcc.gnu.org/PR93623 ("No need to dump gcdas when forking" target GCC 11.0) removed the unuseful and undocumented __gcov_flush.
Close PR38064.
Reviewed By: calixte, serge-sans-paille
Differential Revision: https://reviews.llvm.org/D83149
It seems that after dc52ce424b, all big-endian problems have been fixed.
01899bb4e4 seems to have fixed XFAIL: * of
profile/instrprof-gcov-__gcov_flush-terminate.test
This essentially reverts commit 5a9b792d72 and
93d5ae3af1.
Summary:
When forking in several threads, the counters were written out in using the same global static variables (see GCDAProfiling.c): that leads to crashes.
So when there is a fork, the counters are resetted in the child process and they will be dumped at exit using the interprocess file locking.
When there is an exec, the counters are written out and in case of failures they're resetted.
Reviewers: jfb, vsk, marco-c, serge-sans-paille
Reviewed By: marco-c, serge-sans-paille
Subscribers: llvm-commits, serge-sans-paille, dmajor, cfe-commits, hiraditya, dexonsmith, #sanitizers, marco-c, sylvestre.ledru
Tags: #sanitizers, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D78477
The intent of the `llvm_gcda_start_file` function is that only
one process create the .gcda file and initialize it to be updated
by other processes later.
Before this change, if multiple processes are started simultaneously,
some of them may initialize the file because both the first and
second `open` calls may succeed in a race condition and `new_file`
becomes 1 in those processes. This leads incorrect coverage counter
values. This often happens in MPI (Message Passing Interface) programs.
The test program added in this change is a simple reproducer.
This change ensures only one process creates/initializes the file by
using the `O_EXCL` flag.
Differential Revision: https://reviews.llvm.org/D76206
When the %m filename pattern is used, the filename is unique to each
image, so the cached value is wrong.
It struck me that the full filename isn't something that's recomputed
often, so perhaps it doesn't need to be cached at all. David Li pointed
out we can go further and just hide lprofCurFilename. This may regress
workflows that depend on using the set-filename API to change filenames
across all loaded DSOs, but this is expected to be very rare.
rdar://55137071
Differential Revision: https://reviews.llvm.org/D69137
llvm-svn: 375301
While working on https://reviews.llvm.org/D40900 (which effectively is about enabling compiler-rt on sparc these days), I came across two failing profile testcases:
Profile-sparc :: instrprof-merge-match.test
Profile-sparc :: instrprof-merge.c
Profile-sparcv9 :: instrprof-merge-match.test
Profile-sparcv9 :: instrprof-merge.c
All of them crashed with a SIGBUS in __llvm_profile_merge_from_buffer:
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00012368 in __llvm_profile_merge_from_buffer (
ProfileData=0x2384c <main.Buffer> "\377lprofR\201", ProfileSize=360)
at /vol/llvm/src/llvm/local/projects/compiler-rt/lib/profile/InstrProfilingMerge.c:95
95 SrcDataEnd = SrcDataStart + Header->DataSize;
where Header is insufficiently aligned for a strict-alignment target like SPARC.
Fixed by forcing the alignment to uint64_t, the members of struct __llvm_profile_header,
in the callers.
Tested on sparcv9-sun-solaris2.11.
https://reviews.llvm.org/D64498
llvm-svn: 365805
r355343 was landed and was reverted in r355363 due to build breakage.
This patch adds Linux/Windows support on top of r355343.
In this patch, Darwin should be working with testing case. Linux should be working,
I will enable the testing case in a follwup diff. Windows/Other should be building.
Correct implementation for Other platforms will be added.
Thanks David for reviewing the original diff, helping me with issues on Linux, and
giving suggestions for adding support for Other platforms.
llvm-svn: 355701
Summary:
The changes in https://reviews.llvm.org/D44847 cause load time failure
due to lprofMergeValueProfData in Android libs enabled with profile generation:
"dlopen failed: cannot locate symbol "lprofMergeValueProfData" referenced by..."
Marking lprofMergeValueProfData as hidden so the correct in-module definition
is picked by the linker.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: efriedma, xur, davidxl, llvm-commits
Differential Revision: https://reviews.llvm.org/D55893
llvm-svn: 354064
Summary:
Before this change, check-profile would run, but all tests would be
marked unsupported on Windows. This is the new status of 'check-profile'
after this change:
Testing Time: 6.66s
Expected Passes : 29
Expected Failures : 5
Unsupported Tests : 39
I moved many tests that exercise posix-y features like dlopen and DSOs
into the Posix subdirectory, and ran the tests on Linux to validate my
changes.
These are the remaining tests that I handled on a case by case basis:
- instrprof-path.c
Passes, Fixed some path portability issues
- instrprof-gcov-exceptions.test
Passes, the FileCheck actually succeeds on Windows, so I RUNX'd it
- instrprof-icall-promo.test
XFAILed, probably due to C++ ABI differences in vtables
- instrprof-merge-match.test
- instrprof-merge.c
- instrprof-merging.cpp
XFAILed, These seem like real bugs that need fixing
- instrprof-version-mismatch.c
XFAILed, Overriding the weak version symbol doesn't work
- instrprof-without-libc.c
UNSUPPORTED, test needs an executable symbol table, Windows has none
Reviewers: davidxl, wmi, void
Subscribers: fedor.sergeev, #sanitizers, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D57853
llvm-svn: 353435
Summary: Add a test for coverage for function definition like void foo() { }.
Reviewers: marco-c
Reviewed By: marco-c
Subscribers: delcypher, llvm-commits, #sanitizers, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D53601
llvm-svn: 345625
Summary:
The goal of the patch in D49853 is to display counter on the line of function definition.
So some tests need to be fixed.
Reviewers: marco-c, davidxl
Reviewed By: marco-c
Subscribers: sylvestre.ledru, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49854
llvm-svn: 344229
Summary:
The goal of D49916 is to remove some hit counters from lines like '}'.
So as a consequence, the tests must be fixed.
FYI, after holidays, I'll add more tests.
Reviewers: marco-c, davidxl
Reviewed By: marco-c
Subscribers: delcypher, llvm-commits, #sanitizers, sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D49917
llvm-svn: 342718
Summary: Some tests are broken if patch in D49659 is accepted so this patch fixes them.
Reviewers: marco-c
Reviewed By: marco-c
Subscribers: dberris, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D49721
llvm-svn: 342661
Right now, the counters are added in regards of the number of successors
for a given BasicBlock: it's good when we've only 1 or 2 successors (at
least with BranchInstr). But in the case of a switch statement, the
BasicBlock after switch has several predecessors and we need know from
which BB we're coming from.
So the idea is to revert what we're doing: add a PHINode in each block
which will select the counter according to the incoming BB. They're
several pros for doing that:
- we fix the "switch" bug
- we remove the function call to "__llvm_gcov_indirect_counter_increment"
and the lookup table stuff
- we replace by PHINodes, so the optimizer will probably makes a better
job.
Patch by calixte!
Differential Revision: https://reviews.llvm.org/D51619
llvm-svn: 341977
Summary:
This will make the behavior of __gcov_flush match the GCC behavior.
I would like to rename __gcov_flush to __llvm_gcov_flush (in case of programs linking to libraries built with different compilers), but I guess we can't for compatibility reasons.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: samsonov, vitalybuka, pcc, kcc, junbuml, glider, fhahn, eugenis, dvyukov, davidxl, srhines, chh, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D48538
llvm-svn: 336365
__gcov_flush is hidden.
For applications to dump profiling data of selected .so files,
they can use dlsym to find and call llvm_gcov_flush in each .so file.
Differential Revision: https://reviews.llvm.org/D45454
llvm-svn: 336019
Ellis Hoag