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

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.

 - Hans

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

On Tue, Jun 12, 2012 at 7:53 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
>> 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.
Right, that's a good point.

On i386 Linux, the following code,

  static __thread int x[100000];
  int* get_x() { return x; }

compiled with "clang -shared a.c -o a.so" won't be possible do
dlopen.

The tls_model attribute comes to the rescue:
__attribute((tls_model("global-dynamic"))) will fix this, or
specifying -ftls-model="global-dynamic" on the command-line. But this
only works if we actually give the user the requested model.

Rafael, I think your argument has been that if we're unsure if there
is any reason to strictly preserve the user's choice, we should just
let LLVM choose a better model (and not have to specify any difference
between the "default" and global-dynamic models in the IR).

I'd like to argue the other way around. We see that gcc intentionally
preserves the user's choice ("you've asked for it, therefore you
get
what you've asked for"), and Joerg provided a case (although probably
not common) where it matters. I think that since we are unsure of
whether any code in the wild relies on this, we should choose the
safer and simpler semantics of using the specified model, which means
that we have to tell the difference between the "default" (LLVM gets
to choose the model) and the four specific models.

Thanks,
Hans