search for: thread_loc

Hi all, I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks in advance. Details are as follows. The llvm bc I'm using (which clang produced from a simple c source file, thread_local.c, that has a __thread global, a, and a single functi...

Hi LLVM, I am using 3.0, and I have a question about the __thread in c and thread_local in LLVM IR: O1-O4 and the final linked code behave differently. //////////////////////////////////// The following C code is from the LLVM testcase (SingleSource/UnitTests/Threads/2010-12-08-tls.c) #include <stdio.h> __thread int a = 4; int foo (void) { return a; } int main (void) {...

...__aeabi_read_tp @ load_tp_soft <== get thread pointer (abi dependent) ldr r0, [r0, r3] ldr pc, [sp], #4 .L3: .align 2 .L2: .word a(tpoff) <== offset of "a" .size f, .-f The idea of implementing TLS is to create the "thread_local" keyword. The program above would be converted to this: @a = thread_local global i32 1 ; <i32*> [#uses=1] <== Thread local keyword define i32 @f() { entry: %tmp1 = load i32* @a ; <i32> [#uses=1] ret i32 %tmp1 } With "thread_local&qu...

I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine code that has segment register offset addressing. On 13/05/2010, at 9:26 PM, o.j.sivart at gmail.com wrote: > target triple = "i386-pc-linux-gnu" > > On 13/05/2010, at 9:2...

target triple = "i386-pc-linux-gnu" On 13/05/2010, at 9:25 PM, Anton Korobeynikov wrote: >> int (*FP)() = (int (*)())FPtr; >> int res = FP(); >> >> when the function executes correctly in the case of instead having created a standard global variable. > What is the platform you're running the code on? > > -- > With best regards, Anton

> I note also that this is not a currently unsupported target case where an error should/could/would be produced on attempting to emit code with thread local references. I say this because clang is able to compile both c source with __thread on a global and bc containing a @variable = thread_local global ... and a function that references the thread local global variable to both assembly and machine code that has segment register offset addressing. Maybe TLS stuff is just broken inside JIT? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg St...

Hello, I apologize if this has already been fixed or reported. I believe there is a bug in the way the optimizer deals with thread_local variables. The attached program, test.c, has a thread-local variable "int Foo" and a global variable "int *Ptr". The program takes the following steps: 1) The main thread spawns a new thread and waits 2) The new thread writes Foo = 50 and Ptr = &Foo, then signals the ma...

...ber will get called when the program starts up. I checked the generated IR code and found this is implemented by defining a __cxx_global_var_init() function and marked it as section ".text.startup" and assign it to @llvm.global_ctors. We also know that in C++, the constructor of a static thread_local member will *not* get called when the program starts, but the first time this member is used, I also checked the IR code, this is implemented by calling it's constructor at the usage, and then call __cxa_thread_atexit to register it's destructor. Now I want to add thread_local feature to...

Hello > I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? Thanks for the report. Should be fixed in r103702 -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...e 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...

..., at 5:13 PM, Anton Korobeynikov wrote: > Hello > >> I've been exploring thread local globals in llvm and as part of this investigation I ran llc -march=cpp over a trivial llvm bc file which uses thread local storage for a global. For some reason llc -march=cpp seems to ignore the thread_local and produce code to create a standard global. Is this expected behaviour, a known limitation, or otherwise? > Thanks for the report. Should be fixed in r103702 > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Bergan > Subject: [LLVMdev] Bug Report -- Possible optimizer bug with thread_local variables > my current workaround is to declare Ptr volatile: >    int * volatile Ptr; > Note that if the volatile is moved under the pointer, as in the following: >    volatile int * Ptr; > then the bug reappears, as the load "*Ptr" in main() will be incorrectly optim...

hi guys, i wrote a small program that can load the *.ll file, parse it and execute it. but there is a thread_local global variable. during execution, it says: Cannot allocate thread local storage on this arch! UNREACHABLE executed at /root/llvm/lib/Target/X86/X86JITInfo.cpp:585!. it seems that i did not initialize the executionEngine right or i shouldnot use InitializeNativeTarget()? i don't know how to...

...> 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" @a = thread_local global i32 666 ; <i32*> [#uses=2] define i32 @main() { entry: %retval = alloca i32, align 4 ; <i32*> [#uses=1] "alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0] %tmp = load i32* @a ; &lt...

Hello, The preferred way to do TLS is to use the thread_local keyword. There is x86-64 support for thread_local on ELF; if you need it for other targets, I recommend looking at adapting it. Dan On May 4, 2009, at 2:59 PM, Zoltan Varga wrote: > Hi, > > Here is an updated version of the patch using address space 257. > > Zo...

...ding the value. > > Thanks for your help. > > Kai Thanks for working on this! The first patch looks fine except that it's emitting to .tls when it should be .tls$. Also, you need to add tests. As for the second patch, that's not how MSVC 2010 emits code (and it needs tests). thread_local.c: #ifdef _MSC_VER #define __thread __declspec(thread) #endif __thread int i = 0; int foo() { return i++; } thread_local.asm: PUBLIC _i _TLS SEGMENT _i DD 00H _TLS ENDS PUBLIC _foo EXTRN __tls_array:DWORD EXTRN __tls_index:DWORD ; Function compile flags: /Ogtpy _TEXT SEGMENT _foo PROC ; Fil...

Hi Tom, On Wed, Nov 7, 2012 at 11:43 PM, Tom Bergan <tbergan at cs.washington.edu> wrote: > Hello, > > I apologize if this has already been fixed or reported. I believe there is > a bug in the way the optimizer deals with thread_local variables. The > attached program, test.c, has a thread-local variable "int Foo" and a global > variable "int *Ptr". The program takes the following steps: > > 1) The main thread spawns a new thread and waits > 2) The new thread writes Foo = 50 and Ptr = &...

Hi, If I'm writing a JIT, and want to access the TLS variables of the app containing the JIT, I can't use thread_local since that only works for variables declared in LLVM IL and/or managed by the ExecutionEngine. While this patch allows a JIT to generate the TLS accesses itself, if it knows the tls offset of the variable in question. Zoltan On Tue, May 5, 2009 at 12:16 AM, Dan Gohman <gohm...

> I’ve seen the same problem, but didn’t find solution back then. > I can give a hint that it is related to a thread local storage (notice TLS in the name). > > The same result can be reproduced by this simple program: > > thread_local int x = 0; > int main() { > return 0; > } > >When compiled into IR it produces similar error: > >LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19] > t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [T...

I'm learning the xray library and try if it can be built on windows, in xray_fdr_logging_impl.h line 152 , comment written as // Using pthread_once(...) to initialize the thread-local data structures but at line 175, 183, code written as thread_local pthread_key_t key; // Ensure that we only actually ever do the pthread initialization once. thread_local bool UNUSED Unused = [] { new (&TLSBuffer) ThreadLocalData(); auto result = pthread_key_create(&key, +[](void *) { auto &TLD = *reinterpret_cast<ThreadLocalDa...