r180739 - Emit the TLS intialization functions into a list.

[John McCall]

On Apr 29, 2013, at 5:18 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Mon, Apr 29, 2013 at 5:13 PM, Bill Wendling <isanbard at gmail.com> wrote:
> On Apr 29, 2013, at 5:09 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> > On Mon, Apr 29, 2013 at 3:27 PM, Bill Wendling <isanbard at gmail.com> wrote:
> > Author: void
> > Date: Mon Apr 29 17:27:16 2013
> > New Revision: 180739
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=180739&view=rev
> > Log:
> > Emit the TLS intialization functions into a list.
> >
> > Add the TLS initialization functions to a list of initialization functions. The
> > back-end takes this list and places the function pointers into the correct
> > section. This way they're called before `main().'
> >
> > Why?
> 
> "Why" what? Just as the description says, we place the function pointers into the correct section and, at least on Darwin, the TLS variables are initialized via calls to the those function pointers. Just like global c'tors.
> 
> OK, but why are we switching to eagerly initializing them rather than doing it lazily? That's going to be extremely expensive for applications which start lots of threads (say, by using std::async) and have thread_local variables with non-trivial construction or destruction -- and we still emit the dynamic initialization on every odr-use, so it doesn't seem to save us anything.

This should be a Darwin-specific change.

The Darwin TLS model is that thread-local variables are lazily allocated and initialized, but only at the granularity of a single linkage unit.  That is, as soon as one thread-local variable is touched, every other thread-local variable in that linkage unit is initialized at the same time.  The linker implicitly synthesizes the access functions and, to do so, must receive a list of constructor functions to run, which is what this change collects.  I'm not sure I can fully defend this design, but it's what we've got right now.

However, there is no need to apply this same model to ELF targets.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130429/36150edf/attachment.html>