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

Hans Wennborg hans at chromium.org
Wed Apr 25 04:39:49 PDT 2012


Hi all,

I would like to hear your thoughts on adding support for extending the
IR to allow for explicitly selecting which model to use for
thread-local storage of a variable.

The motivation is to allow Clang to support the "tls_model" variable
attribute [1], as requested in PR9788.

The idea would be to extend the IR to allow an optional TLS-model
argument to the thread_local attribute, like this:

  @x = thread_local(initialexec) global i32 42

Just as it is illegal to specify thread_local for a target that
doesn't support it, specifying a TLS model that isn't supported by the
target would be illegal. If a model is not specified, the target gets
to choose the appropriate model, as it does today.

Clang would need to know which models are supported by which targets
and give an error (or warn and fall back to the default?) if the user
tries to use an unsupported model, just as it currently gives an error
when trying to use thread-local variables on unsupported targets.

The models in question are described in Section 4 of [2]. As far as I
understand, LLVM supports the following models:

 - X86/ELF: general dynamic, initial exec (but not for PIC code?), local exec
 - ARM/ELF: general dynamic, local exec
 - Mips: general dynamic, local dynamic, initial exec, local exec
 - X86 for Darwin and Windows, and XCore, do their own thing
 - The other targets don't support thread-local storage

If this sounds good, I've got patches coming up.

Thanks,
Hans

[1] http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Variable-Attributes.html#index-g_t_0040code_007btls_005fmodel_007d-attribute-1797
[2] http://www.akkadia.org/drepper/tls.pdf



More information about the llvm-dev mailing list