<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Feb 22, 2016 at 3:32 PM Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote:<br>
> A cleaner solution could be adding an IR intrinsic llvm.get_tcb_address()<br>
> and hard code the offset of stack_guard member, since they aren't supposed<br>
> to change.<br>
<br>
It would also be inefficient on architectures that can directly access<br>
TLS variables. I.e. on x86, it is effectively a statically allocated TLS<br>
variable with fixed offset. That can be accessed by a single load --<br>
whereas introducing get_tcb_address first would require a second load.</blockquote><br>Guess I used the wrong intrinsic name - it should be llvm.global_tls_address(), and it should be directly lowered to ISD::GlobalTLSAddress, which is currently used by both x86 and ppc, and ultimately it's referencing fs register on x86_64 and r13 on ppc64le.<br></div></div>