similar to: [LLVMdev] how to execute a *.ll with a thread_local global variable?

Hello, I am trying to use LLVM JIT to emit the following codes and execute both functions in my program, but I get segmentation fault, the problem seems to originate from "thread_local" global variable. my LLVM library is 3.1 and platform is x86 32bit , OS : Ubuntu 10.04 @0 = internal thread_local global i32 522, align 4 define void @setValue(i32 %v) { %1 = alloca i32,

Hi, > I am trying to use LLVM JIT to emit the following codes and execute > both functions in my program, but > > I get segmentation fault, the problem seems to originate from "thread_local" > global variable. > > my LLVM library is 3.1 and platform is x86 32bit , OS : Ubuntu 10.04 try passing -use-mcjit to lli. The old JIT implementation didn't

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

> 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

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

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 machine

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, 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 =

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

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

On Fri, Nov 9, 2012 at 11:23 AM, Hans Wennborg <hans at chromium.org> wrote: > 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

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

> 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

Hi Dong Chen, You can write a ModulePass class and implement a runOnModule method. Inside this method you can access Module::global_iterator and get a reference to all global variables of a module. With this reference, you can change this variable. But be careful, you may need to change also the references to those variables. Have a look to the method GlobalVariable::use_begin and use_end. They

Hi Dong Chen, I realized you are actually executing the IR, right? I am not sure if the things I mentioned apply in that case. Actually, I wrote a optimization pass that modify the IR. It modifies global variables and the final IR is intended to be compiled. A snippet of what I do looks like this: class TestClass : public llvm::ModulePass { public: TestClass() : llvm::ModulePass(TestClass::ID)

hi Eduardo, thanks for your attention, i checked the iterator, but i didn't see any fucntion can return or modify the main memory address of a global variable inside the module. can you provide some reference code or program can achieve this? thank you very much -- View this message in context:

Hello, Bram > 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: Unfortunately, TLS stuff is currently only (probably) supported on X86 and ARM. Nobody tried to implement it on PPC. -- With best regards, Anton Korobeynikov. Faculty of Mathematics

I tried using it on x86 and ended up with the global variable resolving to an invalid pointer.