similar to: [LLVMdev] clang thread-local compilation error on windows

Hello, I have a simple program using aliases to functions, and it seems that the CallGraph doesn't follow these aliases. Here is the example: @alias = alias void ()* @realfunc define void @realfunc() { entry: ret void } define i32 @main() { entry: call void @alias() ret i32 0 } ******* Output of the CallGraph ******* Call graph node <<null

I think you're looking for an inter-procedural post dominator analysis. I don't think there is one in LLVM already, but it should be relatively straightforward. This gives a sound approximation (i.e. no false positives) of something sort-of equivalent to the halting problem: if the program terminates, then block Y was executed. Cheers, Scott On Tue, Oct 2, 2012 at 7:43 PM, Jim Grosbach

Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will execute? For example: extern int x; void foo() { } int main() { if (x) { foo(); } else { foo(); } } I want to be told that the entry block of foo is guaranteed to be

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

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

On Thu, Oct 11, 2012 at 3:56 PM, Stephen Schiffli <sschiffli at gmail.com> wrote: > Hello, I have a simple program using aliases to functions, and it seems that > the CallGraph doesn't follow these aliases. Here is the example: > > @alias = alias void ()* @realfunc > > define void @realfunc() { > entry: > ret void > } > > define i32 @main() { >

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

Okay thanks for the info. The term program termination was probably a poor choice of words. I'm really just trying to build an inter-procedural BasicBlock graph, and then look for postdominance as Scott suggested. I'll go about making my own since it doesn't sound like there is one out there already. Thanks, -Stephen On Tue, Oct 2, 2012 at 5:06 PM, Scott Moore <sdmoore at

Isn't this effectively the halting problem? Consider the case where block Y is the exit block of main() and block X is the entry block of main(). Jim On Oct 2, 2012, at 4:29 PM, Stephen Schiffli <sschiffli at gmail.com> wrote: > Is there any inter-procedural analysis that could tell me if some BasicBlock Y is guaranteed to execute based on my knowledge that BasicBlock X will

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 machine

> 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 all, I was playing with the demo and found that I couldn't use any c++11: warning: 'noexcept' is a keyword in C++11 [-Wc++11-compat] I was wondering if the demo will be updated to LLVM/Clang 3.2 once that finishes, and if it would be possible to enable c++11 support. Thanks, -Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL:

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,

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

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

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

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. > > Zoltan > > On Mon, May 4, 2009 at

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 = [] {

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