Fix the apple build issue caused by r288956

Should be checking if HAVE_CRASHREPORTERCLIENT_H is defined not relying on it having a value.

llvm-svn: 288963

Convert ENABLE_BACKTRACES into a 0/1 definition.

llvm-svn: 282918

Use C++ casts to avoid a warning

warning: cast from type ‘const void*’ to type
‘llvm::PrettyStackTraceEntry*’ casts away qualifiers [-Wcast-qual]
PrettyStackTraceHead = (PrettyStackTraceEntry*)To

Use C++ casts to avoid a warning

warning: cast from type ‘const void*’ to type
‘llvm::PrettyStackTraceEntry*’ casts away qualifiers [-Wcast-qual]
PrettyStackTraceHead = (PrettyStackTraceEntry*)Top;

llvm-svn: 271069

show more ...

Don't use recursion to print out the PrettyStackTrace after a crash. If the
crash was due to a stack overflow, chances are good that this would also cause
a stack overflow.

llvm-svn: 270903

Reorganize the C API headers to improve build times.

Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h

Reorganize the C API headers to improve build times.

Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h
so nothing should change for projects directly including the headers,
but transitive dependencies may be affected.

llvm-svn: 255965

show more ...

Add functions to save and restore the PrettyStackTrace state.

PrettyStackTraceHead is a LLVM_THREAD_LOCAL, which means it's just a global
in LLVM_ENABLE_THREADS=NO builds. If a CrashRecoveryContext

Add functions to save and restore the PrettyStackTrace state.

PrettyStackTraceHead is a LLVM_THREAD_LOCAL, which means it's just a global
in LLVM_ENABLE_THREADS=NO builds. If a CrashRecoveryContext is used with
code that uses PrettyStackEntries, and a crash happens, PrettyStackTraceHead is
currently not reset to its pre-crash value. These functions make it possible
to add a cleanup to such code that does this.

(Not reseting the value then causes the assert in ~PrettyStackTraceEntry() to
fire if the code outside of the CrashRecoveryContext also uses
PrettyStackEntries -- for example, clang when building a module.)

Part of PR11974.

llvm-svn: 244338

show more ...

Fix the preprocessor checks used to determine if backtraces have been enabled.

llvm-svn: 227424

Use the existing build configuration parameter ENABLE_BACKTRACE to compile out all pretty stack trace support when backtraces are disabled.

This has the nice secondary effect of allowing LLVM to con

Use the existing build configuration parameter ENABLE_BACKTRACE to compile out all pretty stack trace support when backtraces are disabled.

This has the nice secondary effect of allowing LLVM to continue to build
for targets without __thread or thread_local support to continue to work
so long as they build without support for backtraces.

llvm-svn: 227423

show more ...

[LPM] Clean up the use of TLS in pretty stack trace and disable it
entirely when threads are not enabled. This should allow anyone who
needs to bootstrap or cope with a host loader without TLS suppor

[LPM] Clean up the use of TLS in pretty stack trace and disable it
entirely when threads are not enabled. This should allow anyone who
needs to bootstrap or cope with a host loader without TLS support to
limp along without threading support.

There is still some bug in the PPC TLS stuff that is not worked around.
I'm getting access to a machine to reproduce and debug this further.
There is some chance that I'll have to add a terrible workaround for
PPC.

There is also some problem with iOS, but I have no ability to really
evaluate what the issue is there. I'm leaving it to folks maintaining
that platform to suggest a path forward -- personally I don't see any
useful path forward that supports threading in LLVM but does so without
support for *very basic* TLS. Note that we don't need more than some
pointers, and we don't need constructors, destructors, or any of the
other fanciness which remains widely unimplemented.

llvm-svn: 227411

show more ...

[LPM] Fix the PPC attribute to be spelled 'global-dynamic'. This should
let the build bot make finish compiling stage2.

llvm-svn: 227391

[LPM] Try to work around a bug with local-dynamic TLS on PowerPC 64.

Sadly, this precludes optimizing it down to initial-exec or local-exec
when statically linking, and in general makes the code slo

[LPM] Try to work around a bug with local-dynamic TLS on PowerPC 64.

Sadly, this precludes optimizing it down to initial-exec or local-exec
when statically linking, and in general makes the code slower on PPC 64,
but there's nothing else for it until we can arrange to produce the
correct bits for the linker.

Lots of thanks to Ulirch for tracking this down and Bill for working on
the long-term fix to LLVM so that we can relegate this to old host
clang versions.

I'll be watching the PPC build bots to make sure this effectively
revives them.

llvm-svn: 227352

show more ...

[LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
tracing code.

Managed static was just insane overhead for this. We took memory fences
and external function calls in every path

[LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
tracing code.

Managed static was just insane overhead for this. We took memory fences
and external function calls in every path that pushed a pretty stack
frame. This includes a multitude of layers setting up and tearing down
passes, the parser in Clang, everywhere. For the regression test suite
or low-overhead JITs, this was contributing to really significant
overhead.

Even the LLVM ThreadLocal is really overkill here because it uses
pthread_{set,get}_specific logic, and has careful code to both allocate
and delete the thread local data. We don't actually want any of that,
and this code in particular has problems coping with deallocation. What
we want is a single TLS pointer that is valid to use during global
construction and during global destruction, any time we want. That is
exactly what every host compiler and OS we use has implemented for
a long time, and what was standardized in C++11. Even though not all of
our host compilers support the thread_local keyword, we can directly use
the platform-specific keywords to get the minimal functionality needed.
Provided this limited trial survives the build bots, I will move this to
Compiler.h so it is more widely available as a light weight if limited
alternative to the ThreadLocal class. Many thanks to David Majnemer for
helping me think through the implications across platforms and craft the
MSVC-compatible syntax.

The end result is *substantially* faster. When running llc in a tight
loop over a small IR file targeting the aarch64 backend, this improves
its performance by over 10% for me. It also seems likely to fix the
remaining regressions seen by JIT users with threading enabled.

This may actually have more impact on real-world compile times due to
the use of the pretty stack tracing utility throughout the rest of Clang
or LLVM, but I've not collected any detailed measurements.

llvm-svn: 227300

show more ...

[C++11] Replace some comparisons with 'nullptr' with simple boolean checks to reduce verbosity.

llvm-svn: 205829

[C++11] Make use of 'nullptr' in the Support library.

llvm-svn: 205697

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also com

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685

show more ...

Make the pretty stack trace be an opt-in, rather than opt-out, facility. Enable pretty
stack traces by default if you use PrettyStackTraceProgram, so that existing LLVM-based
tools will continue to

Make the pretty stack trace be an opt-in, rather than opt-out, facility. Enable pretty
stack traces by default if you use PrettyStackTraceProgram, so that existing LLVM-based
tools will continue to get it without any changes.

llvm-svn: 193971

show more ...

When LLVM is embedded in a larger application, it's not OK for LLVM to intercept crashes. LLVM already has
the ability to disable this functionality. This patch exposes it via the C API.

llvm-svn

When LLVM is embedded in a larger application, it's not OK for LLVM to intercept crashes. LLVM already has
the ability to disable this functionality. This patch exposes it via the C API.

llvm-svn: 193937

show more ...

Make PrettyStackTraceEntry use ManagedStatic for its ThreadLocal.

This was somewhat tricky because ~PrettyStackTraceEntry() may run after
llvm_shutdown() has been called. This is rare and only happ

Make PrettyStackTraceEntry use ManagedStatic for its ThreadLocal.

This was somewhat tricky because ~PrettyStackTraceEntry() may run after
llvm_shutdown() has been called. This is rare and only happens for a common idiom
used in the main() functions of command-line tools. This works around the idiom by
skipping the stack clean-up if the PrettyStackTraceHead ManagedStatic is not
constructed (i.e. llvm_shutdown() has been called).

llvm-svn: 190730

show more ...

Add a new watchdog timer interface. The interface does not permit handling timeouts, so
it's only really useful if you're going to crash anyways. Use it in the pretty stack trace
printer to kill the

Add a new watchdog timer interface. The interface does not permit handling timeouts, so
it's only really useful if you're going to crash anyways. Use it in the pretty stack trace
printer to kill the compiler if we hang while printing the stack trace.

llvm-svn: 177962

show more ...

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...

Add more initializers to quiet a clang warning.

llvm-svn: 141163

Fix a ton of comment typos found by codespell. Patch by
Luis Felipe Strano Moraes!

llvm-svn: 129558

Change all self assignments X=X to (void)X, so that we can turn on a
new gcc warning that complains on self-assignments and
self-initializations.

llvm-svn: 122458

Apparently OS X 10.4 doesn't have __crashreporter_info__.

Try to fix building on the wayback machine.

llvm-svn: 120801

Merge System into Support.

llvm-svn: 120298