[pr19844] Add thread local mode to aliases.

[Reid Kleckner]

This adds some oversharing that we got rid of with the GlobalObject.
 Functions inherit from GlobalValue, but they don't have a thread local
mode.  Is that worth worrying about?

This also allows us to have thread local modes on aliases to functions,
which is awkward.

Do you think it's OK to add asserts to setThreadLocalMode() to make sure we
don't get into these bad states?  FWIW I don't think it's worth having a
GlobalVarAlias and GlobalFuncAlias.

I'm OK with making frontends responsible for putting the thread local mode
on any aliases produced.  Aliases to thread local GVs weren't very useful
before.

+variable). Not all targets support thread-local variables. Optionally, a
+TLS model may be specified:
+
+``localdynamic``
+    For variables that are only used within the current shared library.
+``initialexec``
+    For variables in modules that will not be loaded dynamically.
+``localexec``
+    For variables defined in the executable and only used within it.
+

I noticed this should probably describe the behavior when no model is
specified, i.e. GeneralDynamic.

+The models correspond to the ELF TLS models; see `ELF Handling For

diff --git a/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll
b/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll
index e64375a..a0106d7 100644
--- a/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll
+++ b/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll
@@ -8,7 +8,7 @@ target triple = "i386-pc-linux-gnu"
 @__resp = thread_local global %struct.__res_state* @_res ;
<%struct.__res_state**> [#uses=1]
 @_res = global %struct.__res_state zeroinitializer, section ".bss" ;
<%struct.__res_state*> [#uses=1]

- at __libc_resp = hidden alias %struct.__res_state** @__resp ;
<%struct.__res_state**> [#uses=2]
+ at __libc_resp = hidden thread_local alias %struct.__res_state** @__resp ;
<%struct.__res_state**> [#uses=2]

This test case looks like it was reduced from a real libc.  Do you have a
clang-side patch ready to go for when this lands?

 define i32 @foo() {
 ; CHECK-LABEL: foo:



On Mon, May 26, 2014 at 2:42 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> Now with the language reference updated.
>
> On 26 May 2014 10:26, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> > The attached patch fixes the llvm side of pr19844.
> >
> > This matches gcc's behaviour. It also seems natural given that aliases
> > contain other properties that govern how it is accessed (linkage,
> > visibility, dll storage).
> >
> > Cheers,
> > Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140527/cc4d8d5f/attachment.html>