similar to: [LLVMdev] Dynamically allocate and free variables in stack

Isn't there someone to help me with this issue? I'm very upset about this stupid problem which wasted the whole day. BTW, I can create JIT from main.cpp, but not in the required source file (runtime.cpp), so this is not about linking. Very weird. 2011/9/2 Semion Prihodko <semion.ababo at gmail.com> > I cannot call the constructor explicitly, because ForceJITLinking is a name

Hi, guys. Have a strange problem with LLVM in my project ( https://github.com/ababo/AntOS). Cannot instantiate JIT execution engine (NULL returns; message: Interpreter has not been linked in.). As you can see from the code I call InitializeNativeTarget. Also I tried to directly include the "llvm/ExecutionEngine/JIT.h" header, but with no success. I link with `llvm-config --ldflags

I see two problems in your code 1) you need to #include "llvm/ExecutionEngine/JIT.h" 2) you must pass an empty string to EngineBuilder::setErrorStr. See JIT::createJIT for the reason. Jeff On Sat, Sep 3, 2011 at 8:33 AM, Semion Prihodko <semion.ababo at gmail.com> wrote: > Isn't there someone to help me with this issue? I'm very upset about this > stupid problem

OK, that's my fault. I'm running jitted code on linux x86. 2011/11/9 Duncan Sands <baldrick at free.fr> > Hi Semion, > > > In my case the LLVM is built with assertions, but this doesn't help. From >> your >> answer I conclude that thread-local globals are fully implemented in x86 >> JIT. >> > > you didn't mention the JIT. You

Which version of LLVM? At any rate I don't recall TLS working for the JIT. It may take some work. -eric On Nov 9, 2011, at 4:46 AM, Semion Prihodko wrote: > OK, that's my fault. I'm running jitted code on linux x86. > > 2011/11/9 Duncan Sands <baldrick at free.fr> > Hi Semion, > > > In my case the LLVM is built with assertions, but this doesn't

I use LLVM 2.9. By the way, I have another question. Is landingpad instruction is already implemented in JIT or I should use the old approach with llvm.eh instrinsics? Thanks. 2011/11/9 Eric Christopher <echristo at apple.com> > Which version of LLVM? At any rate I don't recall TLS working for the JIT. > It may take some work. > > -eric > > > On Nov 9, 2011, at

Hi, guys! I write a virtual machine which uses LLVM as back-end code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void

Hi, guys. I'm a newbie to LLVM and have a very simple question. Which instructions should I use (in terms of IRBuilder calls) to allocate an array of bytes in stack (alloca?), then to work with it (from a given offset) as with integer (bitcast?). I mean something like that: unsigned char var[8]; unsigned int offset = 3; int val = *(int*)(&var+offset); /* read */ *(int*)(&var+offset)

In my case the LLVM is built with assertions, but this doesn't help. From your answer I conclude that thread-local globals are fully implemented in x86 JIT. So this is strange... 2011/11/9 Duncan Sands <baldrick at free.fr> > Hi Semion, > > > Really strange situation: when I modify a thread-local GlobalVariable I > get a > > segfault. It seems to be a bug,

Hi! I have a little problem using LLVM and will be happy to get a solution. I need to handle in C++ code an uncaught unwind instruction while calling JIT (now I get segfault). I mean something like nonexistent ExecutionEngine::invokeFunction instead of callFunction. Setting llvm::JITExceptionHandling to true and enclosing the JIT-call within try/catch block does not help here, because there is no

Hi Semion, > In my case the LLVM is built with assertions, but this doesn't help. From your > answer I conclude that thread-local globals are fully implemented in x86 JIT. you didn't mention the JIT. You didn't give any details at all! That's why I was only able to make a generic suggestion. Don't read too much into it. Ciao, Duncan. So > this is strange...

Hello all. At XMOS we are working towards updating the upstream XCore backend for newer versions of the chip. XCore is the XMOS processor. The XCore backend was written by Richard Osborne at XMOS. Richard has moved on. The current code owner in CODE_OWNERS.TXT, Robert Lytton, has also moved on. For some years XMOS has developed the compiler in-house, for new versions of the chip, but not

oops... so how can unwind stack up to invoke call? Is there an alternative to establish a custom exception handling? 2011/11/7 Duncan Sands <baldrick at free.fr> > >> Hi Semion, the unwind instruction has been removed from LLVM. Also, the >> JIT >> and code generators never supported it: it never unwound the stack, it >> just >> resulted in a nasty crash.

Hi, guys. Really strange situation: when I modify a thread-local GlobalVariable I get a segfault. It seems to be a bug, doesn't it? Can u suggest me some solution? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111109/679b7808/attachment.html>

If I give instcombine the following IR: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %c = getelementptr [1 x i8]* %a, i32 0, i32 0 %d = getelementptr [1 x i8]* %b, i32 0, i32 0 %cmp = icmp ult i8* %c, %d ret i1 %cmp } It optimizes it into: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %cmp = icmp slt [1 x i8]* %a, %b ret i1 %cmp } Is this a bug, or are there some semantics of icmp

With LLVM built from trunk I understand I should now use llvm-config --system-libs to get the system libraries to link against when linking against llvm (as of r197664). If run this then llvm-config outputs a blank line before the system libraries, for example on Linux I get: $ llvm-config --system-libs -lz -ltinfo -lrt -ldl -lm If I use --system-libs together with --libs the LLVM libraries

Hi Eric, Could you explain the intent and policy regarding the test-suite body of code. Should the test be left as much as possible as-is (even if technically incorrect)? Should changes only affect the XCore target (#ifdef) or should all targets get the changes? Taking "int32_t main" as an example. The correct return type & argc for main is 'int'. In the XCore tool chain,

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard! -Chris On Mar 9, 2010, at 6:06 AM, Richard Osborne wrote: > On 02/03/10 00:11, Jim Grosbach wrote: >> On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: >> >>> On 01/03/10 21:14, Chris Lattner

Dear developers. We try to make our own backend of llvm for our target machine. Assume that we have the following code in our source code. int i = ( a < b ); The code is translated into r0 <- gt r1 r2 r3 <- and r0 0x1 We think that r3 is not necessary. Is there any way to eliminate it by just modifying our backend? Thank you in advance. Minwook Ahn -------------- next part