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: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

> 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.
I get exactly the same result with gcc 4.7 with and without
-ftls-model=global-dynamic:

movq %gs:0, %eax
addl $x at ntpoff, %eax
> 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).
Not quiet. My main argument is that we are not adding value, since the
linker also does optimizations and the ELF format doesn't list if the
choice of model was explicit or not.

Secondary arguments for going without a "default" value are:

* It is much easier to add it if we find that we do need it than it is
to remove it if we convince ourselves that it is redundant.
* It adds complexity. For example, LLVM would have to distinguish
being run in "compiler mode" versus "linker mode", as the
optimization
is clearly valid at LTO time even if we find a reason for not doing it
during compilation.
>
> Thanks,
> Hans
Cheers,
Rafael

On Thu, Jun 14, 2012 at 9:33 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> 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.
>
> I get exactly the same result with gcc 4.7 with and without
> -ftls-model=global-dynamic:
>
> movq %gs:0, %eax
> addl $x at ntpoff, %eax
Thanks for bearing with me on this. I think it's important that we get it
right.

I could have sworn I tried with -ftls-model yesterday, but apparently
I didn't. Seems it works differently than I assumed (I guess I should
have learnt not too assume things by now). Sorry about that.

The point still stands, though: that code requires the tls_model
attribute to be respected; if the compiler chooses local-exec instead,
it won't be dlopen-able.

The -ftls-model command-line flag has the behavior you describe: the
user sets what the default model should be (global-dynamic if nothing
else is specified), but if the compiler can choose a better model,
that will be used instead. I want to implement this flag too, but that
will be the subject of another patch.


I still think the behaviour in my patch is right. This is an
implementation of a GCC attribute, so unless we have a very good
reason not to, we should make it behave in the same way. And I think
that behaviour makes sense: the attribute is a way for the programmer
to ask for something very specific, so that's what he should get; the
attribute is more like a requirement than a suggestion. AFAIK, that's
how other attributes work too. If I specified the always_inline
attribute on a function, I'd expect the compiler to do its best to
inline it, even if it might not be profitable.
>> 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).
>
> Not quiet. My main argument is that we are not adding value, since the
> linker also does optimizations and the ELF format doesn't list if the
> choice of model was explicit or not.
I think it adds value to make the behaviour the same as GCC's. And
it's not like the difference wouldn't be detectable: the asm is
different, the .o files are different, and the code from the non-PIC
i386 shared lib example wouldn't load with dlopen.

The question is what value it adds to make it work differently from GCC.
> Secondary arguments for going without a "default" value are:
>
> * It is much easier to add it if we find that we do need it than it is
> to remove it if we convince ourselves that it is redundant.
I don't think it is redundant.

(And removing the "default" value while preserving backwards
compatibility just means we've wasted one value in the bitcode
encoding.)
> * It adds complexity. For example, LLVM would have to distinguish
> being run in "compiler mode" versus "linker mode", as
the optimization
> is clearly valid at LTO time even if we find a reason for not doing it
> during compilation.
I don't know enough about how the LTO code works to comment on this one.

Thanks,
Hans