<div dir="ltr"><div>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?</div><div><br></div>
<div>This also allows us to have thread local modes on aliases to functions, which is awkward.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>+variable). Not all targets support thread-local variables. Optionally, a</div>
<div>+TLS model may be specified:</div><div>+</div><div>+``localdynamic``</div><div>+    For variables that are only used within the current shared library.</div><div>+``initialexec``</div><div>+    For variables in modules that will not be loaded dynamically.</div>
<div>+``localexec``</div><div>+    For variables defined in the executable and only used within it.</div><div>+</div><div><br></div><div>I noticed this should probably describe the behavior when no model is specified, i.e. GeneralDynamic.</div>
<div><br></div><div>+The models correspond to the ELF TLS models; see `ELF Handling For</div><div><br></div><div>diff --git a/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll b/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll<br>
</div><div><div>index e64375a..a0106d7 100644</div><div>--- a/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll</div><div>+++ b/test/CodeGen/X86/2008-03-12-ThreadLocalAlias.ll</div><div>@@ -8,7 +8,7 @@ target triple = "i386-pc-linux-gnu"</div>
<div> @__resp = thread_local global %struct.__res_state* @_res<span class="" style="white-space:pre">          </span>; <%struct.__res_state**> [#uses=1]</div><div> @_res = global %struct.__res_state zeroinitializer, section ".bss"<span class="" style="white-space:pre">            </span>; <%struct.__res_state*> [#uses=1]</div>
<div> </div><div>-@__libc_resp = hidden alias %struct.__res_state** @__resp<span class="" style="white-space:pre">         </span>; <%struct.__res_state**> [#uses=2]</div><div>+@__libc_resp = hidden thread_local alias %struct.__res_state** @__resp<span class="" style="white-space:pre">           </span>; <%struct.__res_state**> [#uses=2]</div>
<div><br></div><div>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?</div><div> </div><div> define i32 @foo() {</div><div> ; CHECK-LABEL: foo:</div>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 2:42 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Now with the language reference updated.<br>
<div class="HOEnZb"><div class="h5"><br>
On 26 May 2014 10:26, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
> The attached patch fixes the llvm side of pr19844.<br>
><br>
> This matches gcc's behaviour. It also seems natural given that aliases<br>
> contain other properties that govern how it is accessed (linkage,<br>
> visibility, dll storage).<br>
><br>
> Cheers,<br>
> Rafael<br>
</div></div></blockquote></div><br></div>