Since the profile can come from 32-bit machines, the reader needs to
check the pointer size. Change the magic number to facilitate this.
<rdar://problem/16400648>
llvm-svn: 204556
This is a bit of a stab in the dark as I'm not sure I've got these
source files compiling correctly locally. (and the warning only
reproduces on a 32bit build anyway)
llvm-svn: 204521
Apparently, MSVC has stdint.h now? Let's see if the buildbots complain.
I'm not convinced that the build system is even set up for MSVC to build
this file, but...
llvm-svn: 204515
Write __llvm_profile_write_buffer(), which uses the same logic as
__llvm_profile_write_file(), but writes directly to a provided `char*`
buffer instead.
<rdar://problem/15943240>
llvm-svn: 204499
It was misguided to plan to rely on __llvm_profile_write_buffer() in
__llvm_profile_write_file(). It's less complex to duplicate the writing
logic than to mmap the file.
Since it's here to stay, move `FILE*`-based writing logic into
InstrProfilingFile.c.
<rdar://problem/15943240>
llvm-svn: 204498
Move functions around to prepare for some other changes.
- Merge InstrProfilingExtras.h with InstrProfiling.h. There's no
benefit to having these split.
- Rename InstrProfilingExtras.c to InstrProfilingFile.c.
- Split actual buffer writing code out of InstrProfiling.c into
InstrProfilingBuffer.c.
- Drive-by corrections of a couple of header comments.
<rdar://problem/15943240>
llvm-svn: 204497
Add logic to do a printf-style substitution of %p for the process pid in
the filename.
It's getting increasingly awkward to work on lib/profile without test
infrastructure. This needs to be fixed!
<rdar://problem/16383358>
llvm-svn: 204414
These functions are in the profile runtime. PGO comes later.
Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.
<rdar://problem/15943240>
llvm-svn: 204391
__llvm_pgo_write_default_file() was a bad name, since it checked the
environment (it wasn't just a default file).
- Change __llvm_pgo_write_file() to __llvm_pgo_write_file_with_name()
and make it static.
- Rename __llvm_pgo_write_default_file() to __llvm_pgo_write_file().
- Add __llvm_pgo_set_filename(), which sets the filename for
subsequent calls to __llvm_pgo_write_file().
<rdar://problem/15943240>
llvm-svn: 204381
Instead of relying on explicit static initialization from translation
units, create a new file, InstrProfilingRuntime.cc, with an
__llvm_pgo_runtime variable. After this commit (and its pair in clang),
the driver will create a use of this variable. Unless the user defines
their own version, the new object file will get pulled in, including
that C++ static initialization that calls
__llvm_pgo_register_write_atexit.
The result is that, at least on Darwin, static initialization typically
consists of a single function call, which registers a writeout functino
atexit. Furthermore, users can skip even this behaviour by defining
their own __llvm_pgo_runtime.
<rdar://problem/15943240>
llvm-svn: 204380
Currently we register instrumentation data at runtime to determine the
bounds of the sections where the data lives. Soon we'll implement
platform-specific linker magic to determine this at link time.
Move this logic to a separate file, so that our build system can choose
the correct platform-specific code.
No functionality change intended.
<rdar://problem/15943240>
llvm-svn: 204299
Split implementation files along a uses-libc/shouldn't-use-libc
boundary.
- InstrProfiling.h is a shared header.
- InstrProfiling.c provides an API to extract profiling data from the
runtime, but avoids the use of libc. Currently this is a lie:
__llvm_pgo_write_buffer() uses `FILE*` and related functions. It
will be updated soon to write to a `char*` buffer instead.
- InstrProfilingExtras.c provides a more convenient API for
interfacing with the profiling runtime, but has logic that does (and
will continue to) use libc.
<rdar://problem/15943240>
llvm-svn: 204268
In instrumentation-based profiling, we need a set of data structures to
represent the counters. Previously, these were built up during static
initialization. Now, they're shoved into a specially-named section so
that they show up as an array.
As a consequence of the reorganizing symbols, instrumentation data
structures for linkonce functions are now correctly coalesced.
This is the first step in a larger project to minimize runtime overhead
and dependencies in instrumentation-based profilng. The larger picture
includes removing all initialization overhead and making the dependency
on libc optional.
<rdar://problem/15943240>
llvm-svn: 204079
This will break without the corresponding change in clang, which I've
reverted until I figure out how to get it to link properly.
This reverts commit r203710.
llvm-svn: 203713
Also rename the default output file from "pgo-data" to "default.profdata".
The ".profdata" suffix is consistent with the name of the new llvm-profdata
tool.
llvm-svn: 201808
Adding the ARM RT sources to the CMake files, and enabling some
sanitizers to also build on ARM. This is far from supported or
production quality, but enabling it to build will get us errors
that we can actually fix.
Having said that, the Compiler-RT and the Asan libraries are
know to work on some variations of ARM.
llvm-svn: 200546
Otherwise on (some) 64-bit systems, -Wformat will trigger a warning
because uint64_t is an 'unsigned long' not an 'unsigned long long'.
Consequently, PGOProfiling.c would fail to build if -Werror and
-Wformat are both enabled.
llvm-svn: 198644
This is fairly minimal support for instrumentation based PGO. The data
format is inefficient, and the output file name is hardcoded to
pgo-data.
llvm-svn: 198638
(thanks!) by deferring the free of the filename until we finish writing
the coverage data to that file.
Bill, let me know if you'd prefer a different approach!
llvm-svn: 184895
through Bill's patch:
1) Correctly test the file descriptor after the sceond attempt at
creating the file.
2) Make the filename a global so that we can issue error messages from
other routines.
3) Check errno in several places and print it out so that errors are
easier to track down.
I don't really expect any of these to fix the current failures I'm
seeing, but I'm hopeful they'll at least let me debug them.
llvm-svn: 184799
We really need the C standard library to be available to implement the
profiling runtime library reasonably, and replicating everything in the
SDKs tree really isn't addressing any problems we have. Notably, all of
the sanitizer runtimes take the same approach, and this isn't a library
which could end up in a bootstrapping problem where the system headers
aren't even available.
This will hopefully prevent subsequent changes which start using various
other bits of C standard library to make things more debuggable.
llvm-svn: 184798
Using fwrite and fread was very *very* slow. The resulting code was multiple
times slower than GCC's implementation of gcov. Replace the fwrite/fread system
with an mmap() version.
If the `.gcda' file doesn't exist, we (re)allocate a buffer that we write
into. That gets written to the `.gcda' file in one chunk. If the `.gcda' file
already exists, we simply mmap() the file, modify the mapped data, and use
msync() to write the contents out to disk. It's much easier than implementing
our own buffering scheme, and we don't have to use fwrite's and fread's
buffering.
For those who are numbers-oriented, here are some timings:
GCC Verison
-----------
`.gcda' files don't exist: 23s
`.gcda' files do exist: 14s
LLVM Version (before this change)
---------------------------------
`.gcda' files don't exist: 28s
`.gcda' files do exist: 28s
LLVM Version (with this change)
-------------------------------
`.gcda' files don't exist: 18s
`.gcda' files do exist: 4s
It's a win-win-win-win-lose-win-win scenario!
<rdar://problem/13466086>
llvm-svn: 182563
The calls to fwrite/fread can be very expensive. GCC avoids this by using a
buffer to read and write from the file, thus limiting the number of fwrite/fread
calls.
<rdar://problem/13466086>
llvm-svn: 181924
The fread / fwrite calls were happening for each timer. However, that could be
pretty expensive for a large number of timers. Instead, read and write the
timers in one call.
This gives ~10% speedup in compilation time.
llvm-svn: 179990
This function replaces the call of `atexit' from being generated in the compile
units. Basically, it registers the "writeout" and "flush" functions (if
present). It will generate calls to the `atexit' function for cleanups and final
writeout functions, but only once. This is better than checking for `main',
because a library may not have a `main' function in it.
<rdar://problem/12439551>
llvm-svn: 177578
It may be prohibitively expensive to write out >1000 files at the same time. So
we would rather emit them serially. These functions allow the GCOV
implementation to register the functions that writeout the GCOV information per
compile unit. At exit, they are written.
<rdar://problem/12439551>
llvm-svn: 177436
The __llvm_gcov_flush() functions only work for the local compile unit. However,
when __gcov_flush() is called, the user expects all of the counters to be
flushed, not just the ones in the current compile unit.
This adds some library functions that register the flush functions. It also
defined __gcov_flush() so that loops through that list and calls the functions.
PR15191 & <rdar://problem/13167507>
llvm-svn: 177337
it. Fortunately, versions of gcov that predate the extra checksum also ignore
any extra data, so this isn't a problem. This matches the API change made in
r176745.
llvm-svn: 176746
didn't delete the original, and now they've diverged. I have no idea what's
going on. Apply my patch in r176173 to this one too, this one looks newer?
llvm-svn: 176236
With the advent of the __llvm_gcov_flush function, we need to be able to merge
counts into the .gcda files in an intelligent manner. This involves reading the
file if it exists, adding the counts together, and then writing the results.
<rdar://problem/12185886>
llvm-svn: 163923
sets of functions/objects into high level groups. Currently we have "builtins"
(the main compiler-rt code), "profile", and "asan".
- Use this to define CommonFunctions and ArchFunctions to only reference the
builtins functions.
llvm-svn: 145674
Duncan P. N. Exon Smith