[LLVMdev] Adding support for explicitly specified TLS models (PR9788)

[Joerg Sonnenberger]

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