Runtime code implicitly depends on the defintions and const
values defined in LLVM proper, but currently such dependency
is made implicitly by duplicating code across two dirs. As
part of the PGO cleanup effort, there will be changes to share
common sources. This is a preparation patch to enable it (NFC).
Differential Revision: http://reviews.llvm.org/D14487
llvm-svn: 252570
On Linux, the profile runtime can use __start_SECTNAME and __stop_SECTNAME
symbols defined by the linker to locate the start and end location of
a named section (with C name). This eliminates the need for instrumented
binary to call __llvm_profile_register_function during start-up time.
llvm-svn: 250200
Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists.
This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features.
Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov
Subscribers: beanz, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D12292
llvm-svn: 245970
Summary: This patch consolidates add_compiler_rt_osx_static_runtime and add_compiler_rt_darwin_dynamic_runtime into a single new function add_compiler_rt_darwin_runtime.
Reviewers: filcab, samsonov, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12106
llvm-svn: 245317
When the file is initialized, this patch checks whether the path
specifies a directory. If so, it creates the directory tree before
truncating the file.
Use default.profdata instead of pgo-data for default indexed profile name.
llvm-svn: 241824
Summary:
Use CMake's cmake_parse_arguments() instead.
It's called in a slightly different way, but supports all our use cases.
It's in CMake 2.8.8, which is our minimum supported version.
CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc):
http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments
Since I was already changing these calls, I changed ARCH and LIB into
ARCHS and LIBS to make it more clear that they're lists of arguments.
Reviewers: eugenis, samsonov, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10529
llvm-svn: 240120
This change removes libclang_rt.profile-pic-<arch>.a version of
profile runtime. Instead, it's sufficient to always build
libclang_rt.profile-<arch>.a with -fPIC, as it can be linked into
both executables and shared objects.
llvm-svn: 221952
These tests were XPASS-ing on Linux bots creating Mach-O, which makes
sense, since the real difference is the object format.
I'm hoping a short-term fix to get these tests passing on ELF is to
create two copies of the runtime -- one built with -fPIC, and one
without. A follow-up patch will change clang's driver to pick between
them depending on whether `-shared` is specified.
llvm-svn: 208947
Add the test infrastructure for testing lib/profile and a single test.
This initial commit only enables the tests on Darwin, but they'll be
enabled on Linux soon after.
<rdar://problem/16458307>
llvm-svn: 205256
Soon there will be an option to build compiler-rt parts as shared libraries
on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042
by Yuri Gribov.
llvm-svn: 205183
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
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
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
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
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
Xinliang David Li