Summary:
* Don't bother using a thread wrapper when the variable is known to
have constant initialization.
* Emit the thread wrapper as discardable-if-unused in TUs that don't
contain a definition of the thread_local variable.
* Don't emit the thread wrapper at all if the thread_local variable
is unused and discardable; it will be emitted by all TUs that need
it.
Reviewers: rjmccall, jdoerfert
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67429
llvm-svn: 371767
-fno-use-cxx-atexit is used
This matches the GCC behavior, __cxa_thread_atexit should be permissible
even though cxa_atexit is disabled.
Differential Revision: https://reviews.llvm.org/D63283/
llvm-svn: 363288
Summary:
Teach clang to mark thread wrappers for thread_local variables with
hidden visibility when the original variable is marked with hidden
visibility. This is necessary on Darwin which exposes the thread wrapper
instead of the thread variable. The thread wrapper would previously
always be created with default visibility unless it had
linkonce*/weak_odr linkage.
Reviewers: rjmccall
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D56818
llvm-svn: 351457
__tls_guard.
__tls_guard can only ever transition from 0 to 1, and only once. This
permits LLVM to remove repeated checks for TLS initialization and
repeated initialization code in cases like:
int g();
thread_local int n = g();
int a = n + n;
where we could not prove that __tls_guard was still 'true' when checking
it for the second reference to 'n' in the initializer of 'a'.
llvm-svn: 345774
This reverts commit https://reviews.llvm.org/rL344150 which causes
MachineOutliner related failures on the ppc64le multistage buildbot.
llvm-svn: 344526
This is currently a clang extension and a resolution
of the defect report in the C++ Standard.
Differential Revision: https://reviews.llvm.org/D46441
llvm-svn: 344150
initialization functions to 'cxx_fast_tlscc'.
This fixes a bug where instructions calling initialization functions for
thread-local static members of c++ template classes were using calling
convention 'cxx_fast_tlscc' while the called functions weren't annotated
with the calling convention.
rdar://problem/40447463
Differential Revision: https://reviews.llvm.org/D47354
llvm-svn: 333447
* Do not initialize these variables when initializing the rest of the
thread_locals in the TU; they have unordered initialization so they can be
initialized by themselves.
This fixes a rejects-valid bug: we would make the per-variable initializer
function internal, but put it in a comdat keyed off the variable, resulting
in link errors when the comdat is selected from a different TU (as the per
TU TLS init function tries to call an init function that does not exist).
* On Darwin, when we decide that we're not going to emit a thread wrapper
function at all, demote its linkage to External. Fixes a verifier failure
on explicit instantiation of a thread_local variable on Darwin.
llvm-svn: 291865
This makes sure we don't generate a lot of code to spill/reload
CSRs when calling tls_init from the access functions.
This helps performance when tls_init is not inlined into the access
functions.
llvm-svn: 263854
This commit is a follow-up to r251734, r251476, and r249735, which fixes
a bug where function attributes were not attached to thread local
wrapper functions.
rdar://problem/20828324
llvm-svn: 257865
This is about how we handle static member of a template. Before this commit,
we use internal linkage for the IR thread-local variable, which is inefficient.
With this commit, we will start to follow Itanium C++ ABI.
rdar://problem/23415206
Reviewed by John McCall.
llvm-svn: 252814
We used to emit the store prior to branch in the entry block. To make it more
efficient, this commit moves it to the init block. We still mark as initialized
before initializing anything else.
llvm-svn: 252777
This will be used for old targets like Android that do not
support ELF TLS models.
Differential Revision: http://reviews.llvm.org/D10524
llvm-svn: 243441
Summary:
Update our mangling to match the discussion on cxx-abi-dev.
This involves using a seq-id instead of an optional number.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3631
llvm-svn: 208140
We would sometimes incorrectly give a thread-wrapper external linkage
instead of internal linkage if we had only CodeGen'd it's declaration,
not it's definition.
This fixes PR19655.
llvm-svn: 207988
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
llvm-svn: 207451
were lacking ExprWithCleanups nodes in some cases where the new approach to
lifetime extension needed them).
Original commit message:
Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183859
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183721
non-constant constructors or non-trivial destructors. Plus bugfixes for
thread_local references bound to temporaries (the temporaries themselves are
lifetime-extended to become thread_local), and the corresponding case for
std::initializer_list.
llvm-svn: 179496
Richard Smith