[llvm-commits] [LLVMdev] [Patch, RFC] Re: Adding support for explicitly specified TLS models (PR9788)

[Joerg Sonnenberger]

On Tue, Jun 12, 2012 at 07:21:17PM +0100, Hans Wennborg wrote:
> On Tue, Jun 12, 2012 at 7:05 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Tue, Jun 12, 2012 at 12:36:28PM -0400, Rafael Espíndola wrote:
> >> >> Do you know what is the rationale for that? The static linker will
> >> >> optimize it anyway (but not do as good a job as the compiler could).
> >> >
> >> > codegen can be more efficient. E.g. less or no calls to __tls_get_addr
> >> > needed.
> >>
> >> My point also :-) What I was asking for a rationale on was *not* doing
> >> the optimization in the compiler.
> >
> > Ah, sorry. Because the compiler might not know it yet. Consider linking
> > code compiled with -fPIC into the main binary, either using PIE or not.
> 
> Right, but the issue we're discussing here, is why GCC chooses to not
> optimize a variable like this:
> 
>   static __thread int __attribute((tls_model("global-dynamic"))) x;
> 
> even if it could (e.g. when compiled without -fpic).
> 
> We're trying to figure out if there's a good reason for this, and if
> we want to mimic that behaviour in LLVM, or if we should just take the
> tls_model attribute as a starting point, and choose a better model if
> we can.

On i386, non-PIC code can be used in shared libraries. If the TLS
variable itself is large, forcing global-dynamic makes sense. No idea if
anyone is insane enough to do that, but that's the case where honouring
the user request would make a difference.

Joerg