llvm dev - Apr 2012 - [LLVMdev] Adding support for explicitly specified TLS models (PR9788)

On Thu, Apr 26, 2012 at 01:10, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
>> > For ELF, it doesn't make sense to reject one as it can always
be
>> > relaxed. An application program shouldn't have to worry about
that, it
>> > is just an implementation detail.
>>
>> I'd be fine with that.
>>
>> (Clang should still worry about it though, so it can provide a
"the
>> TLS model you selected is not supported by the target, it will fall
>> back to another one" warning.)
>
> There is no point in warning about it. Basically, anything but global
> dynamic a pure performance optimisation.
It was pointed out in #llvm that programs that mix C and assembly to
access thread-local variables would break if the TLS model isn't what
they specify, so I still think there's a case for warning about it.

 - Hans

On Fri, Apr 27, 2012 at 09:19:32AM +0100, Hans Wennborg
wrote:
> On Thu, Apr 26, 2012 at 01:10, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> >> > For ELF, it doesn't make sense to reject one as it can
always be
> >> > relaxed. An application program shouldn't have to worry
about that, it
> >> > is just an implementation detail.
> >>
> >> I'd be fine with that.
> >>
> >> (Clang should still worry about it though, so it can provide a
"the
> >> TLS model you selected is not supported by the target, it will
fall
> >> back to another one" warning.)
> >
> > There is no point in warning about it. Basically, anything but global
> > dynamic a pure performance optimisation.
> 
> It was pointed out in #llvm that programs that mix C and assembly to
> access thread-local variables would break if the TLS model isn't what
> they specify, so I still think there's a case for warning about it.
Do they? In which specific constellation? The attribute is used only by
codegen and the relocations for the different access methods can
co-exist.

My main concern is code that needs to run across a wide number of platforms.
Requesting a specific hot variable to be initial-exec can have a huge impact
on runtime on platforms that supports this model like x86. It would be
painful to have to use #if wrappers to workaround some bogus warning on
platforms where initial-exec and global-dynamic are the same.

Joerg

On Fri, Apr 27, 2012 at 12:12, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
>> It was pointed out in #llvm that programs that mix C and assembly to
>> access thread-local variables would break if the TLS model isn't
what
>> they specify, so I still think there's a case for warning about it.
>
> Do they? In which specific constellation? The attribute is used only by
> codegen and the relocations for the different access methods can
> co-exist.
I don't know exactly what he meant. I figured that accessing a
thread-local variable via different access models (one from c code and
one from hand-written asm) would be a problem, but maybe it isn't in
practice.
> My main concern is code that needs to run across a wide number of
platforms.
> Requesting a specific hot variable to be initial-exec can have a huge
impact
> on runtime on platforms that supports this model like x86. It would be
> painful to have to use #if wrappers to workaround some bogus warning on
> platforms where initial-exec and global-dynamic are the same.
I see your point. FWIW, gcc doesn't warn about this either, as far as
I can tell.

 - Hans