similar to: [LLVMdev] Handling of thread_local globals by llc -march=cpp

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

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

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

Thanks for the quick reply and fix. Now it just means I have to hunt further in exploring why, in my simple test program, replacing the following line of code: GlobalVariable* global = new GlobalVariable(*MyModule, IntegerType::get(getGlobalContext(), 32), false, GlobalValue::ExternalLinkage, 0, "global"); with the following line of code: GlobalVariable* global = new

> 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

> 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 Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

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) {

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

Hi, I created a global char array, char buffer[1024]. I want to call a function to append the string information to the buffer repeatedly. For example, I need to implement the following code, where length, a, b, c, are global variables. int length = 0; length += sprintf(buffer+length, "str%d", a); length += sprintf(buffer+length, "str%c", b); length += sprintf(buffer+length,

I am new to LLVM API. and I am experimenting with it. I want to create Global Variables in a module. I am able to create local variables using IRBuilder class. I tried using GlobalVariable class to create global variables. but it doesn't work. my code looks like this: Module* mod = new Module("test", getGlobalContext()); Constant* c = mod->getOrInsertFunction("main",

Hi During a pass, the XCore target lowers thread local global variables by turning them into global variable arrays indexed by the (max 8) thread ID. (see XCoreLowerThreadLocal.cpp) This works fine for instructions e.g. GetElementPtrInst But can't be done for constants e.g. GetElementPtrConstantExpr Thus I would like to replace GetElementPtrConstantExpr with GetElementPtrInst when it is

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 =

For everyone understand which code must be emitted to implement TLS, I will paste the code generated by gcc for a simple function: __thread int a = 1; int f(){ return a; } gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi): .global a .section .tdata,"awT",%progbits <== special section for tls symbols .align 2 .type a, %object

We know that in C++, the constructor of a static member 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

On 07/07/2010 08:20 PM, Eric Christopher wrote: > > On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > >> Which one is correct ? >> - movl $tm_nest_level at TPOFF, %ecx >> or >> - movq $tm_nest_level at TPOFF, %rcx >> or >> - movl tm_nest_level at TPOFF, %ecx >> > > I believe this is initial exec and so from: > >

subramanyam wrote: > > I am new to LLVM API. and I am experimenting with it. > I want to create Global Variables in a module. > I am able to create local variables using IRBuilder class. I tried using > GlobalVariable class to create global variables. > but it doesn't work. my code looks like this: > > Module* mod = new Module("test", getGlobalContext()); >

Hi all, I would like to hear your thoughts on adding support for extending the 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

On Sun, Dec 4, 2011 at 9:18 AM, Kai <kai at redstar.de> wrote: > Hi! > > LLVM currently does not implement the implicit TLS model on Windows. This > model is easy: > > - a thread local variable ends up in the .tls section > - to access a thread local variable, you have to do >  (1) load pointer to thread local storage from TEB >      On x86_64, this is gs:0x58, on

> 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; >