[LPM] Rip all of ManagedStatic and ThreadLocal out of the pretty stack
authorChandler Carruth <chandlerc@gmail.com>
Wed, 28 Jan 2015 09:52:14 +0000 (09:52 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Wed, 28 Jan 2015 09:52:14 +0000 (09:52 +0000)
commit16b670ec2027af8699dd182e95d33076914d00eb
treecf0102460ded721d05f44d14846bba50e1237a01
parent5b0d3e3f3add708373a26c6cfa8fd7145e2f3ecd
[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
llvm/lib/Support/PrettyStackTrace.cpp