search for: globaltlsaddress

...statically allocated TLS > variable with fixed offset. That can be accessed by a single load -- > whereas introducing get_tcb_address first would require a second load. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/6fb9314a/attachment.html>

...register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or 3) Create a generic ISD::GET_GLOBAL_TLS_ADDRESS and intrinsic llvm.get_global_tls_address(), and lower them to target specific ISD. No target specific intrinsic is needed. I was wrong about ISD::GlobalTlsAddress, since it requires a GlobalValue object. I prefer 3), since it's less hacky than 2) and less repetitive than 1). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/4d642a28/attachment.html>

Hi, This weekend, I've noticed that GlobalVariable's could be declared as thread-local in LLVM 2.0. However, when using it on a small example (OSX), I got the following error: ========= Cannot yet select: 0x56059f0: i32 = GlobalTLSAddress <i32* @a> 0 Abort trap ========= This is the example code: ========= ; ModuleID = 'test.o' target datalayout = "E-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0 :64" target triple = "powerpc-apple-darwin8.9.0...

Hi, is TLS already supposed to work on x86-64? I get the following error: Cannot yet select: 0xec9330: i64 = GlobalTLSAddress <%struct.stm_tx_t** @thread_tx> 0 llc((anonymous namespace)::PrintStackTrace()+0x15)[0xa10495] llc((anonymous namespace)::SignalHandler(int)+0x216)[0xa10826] /lib/libc.so.6[0x2b6da40a5ca0] /lib/libc.so.6(gsignal+0x35)[0x2b6da40a5c45] /lib/libc.so.6(abort+0x110)[0x2b6da40a75c0] llc[0x73c0a5]...

I found a bit weird to use address space for this, since the offset of getting stack_guard in TCB is, unfortunately, negative: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610 In my understanding an address space is referring to a segment register (-on powerpc 32bit; or SLB entry on powerpc 64bit?) with a non-negative offset value, so that it's actually accessing

When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put the stack guard into TCB. x86 fixed this issue by injecting a special address space (which is later translated to TCB register access) and hard code the offset of stack_guard, but I don't see a easy way to

...AG); case ISD::BR_CC: return LowerBR_CC(Op, DAG); - case ISD::GlobalAddress: return LowerGlobalAddressELF(Op, DAG); + case ISD::GlobalAddress: return Subtarget->isTargetDarwin() ? LowerGlobalAddressDarwin(Op, DAG) : + LowerGlobalAddressELF(Op, DAG); case ISD::GlobalTLSAddress: return LowerGlobalTLSAddress(Op, DAG); case ISD::JumpTable: return LowerJumpTable(Op, DAG); case ISD::SELECT: return LowerSELECT(Op, DAG); diff --git a/lib/Target/AArch64/AArch64ISelLowering.h b/lib/Target/AArch64/AArch64ISelLowering.h index 7c7d038..ee31a10 100644 --- a/lib/Target/AArch64/A...