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

[Hans Wennborg]

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