similar to: [LLVMdev] is this a bug of llvm::JIT::getPointerToBasicBlock?

On 08/27/2010 11:05, Dale Johannesen wrote: >>>> Function only has on BB. Is this wrong that it has both >>>> TCRETURNri64 and RET in one BB? >>> >>> Yes, that is wrong. The reason emitEpilogue isn't lowering the >>> TCRETURN is that it doesn't see it, it only sees the RET. The real >>> problem will be where that RET is

On 08/27/2010 11:32, Yuri wrote: > As I understand only one of TCRETURNri64 and RET should be created. > I have sources of rev.112200. > > Here is the stack when TCRETURNri64 instruction is created: > #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr > (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}, > NoImp=false) at

Hi all, I need to run c++ prgrams using lli. However, I find lli cannot handle the alias instruction correctly. Following is an example: ------------ example.cc ------------- #include <iostream> using namespace std; class cls { public: cls(); ~cls(); }; cls::cls() { cout << "constructor" << endl; }; cls::~cls() { cout <<

Hey, I have a situation where in I need to intercept a call to a particular function and return a pointer to a separate implementation of that function using JIT. The scenario is like this: 1. A test code or client code calls a function A() for which a dummy implementation is provided in a library which the test code/client links with during compilation. 2. I create the .bc using -emit-llvm and

On 08/27/2010 12:13, Dale Johannesen wrote: > I don't think I believe this; emitPrologue should not be generating a > TCRETURN at all, and line 1037 is generating a PROLOG_LABEL. Why do > you say it's a TCRETURN? Sorry, my bad. I have set breakpoints by MI addresses. But it turns out that these addresses were reused and the second MIs created at these particular addressed

Hi Everyone, When I compile a program with clang with debug symbols enabled and I try to run it using the JIT (lli) I get the following error message. I am running on Lion (10.7.4). Thanks. George >> pseudo instructions should be removed before code emission UNREACHABLE executed at /Users/JD/Software/llvm3.1/llvm-3.1.src/lib/Target/X86/X86CodeEmitter.cpp:736! 0 lli

Hi all, I'm trying to extend the Dalvik VM to load some LLVM assembly from the SD card, JIT it, and execute it. I'm using AOSP 4.0.4, a Galaxy Nexus, and the version of LLVM that comes in the external project of AOSP (LLVM 2.8, I believe?) I have the following LLVM assembly: target datalayout =

Hi Everyone, I've managed to create a small example that reproduces the error that I'm seeing when generating code, or running the interpreter: ----------------------------------------------------------------------- @llvm_gc_root_chain = global i8* null declare i8* @malloc(i32) declare void @llvm.gcroot(i8**, i8*) nounwind define i32 @main() gc "shadow-stack" { %value =

Hi, I've been implementing a compiler that targets LLVM, and was looking into using the shadow-stack gc strategy. Currently, I build the runtime with clang (using -emit-llvm), and then link that with the LLVM bitcode output from my compiler using llvm-ld. This works fine without the gc strategy annotations and use of the llvm.gcroot intrinsic, but adding them causes some odd behavior: the

Yes. It appears that a bad reference to DataLayout was passed to MachineJumpTableInfo::getEntrySize. I'm using LLVM as a pre-compiled Ubuntu package for this work, so I can't do much more in GDB without building from source. Program received signal SIGSEGV, Segmentation fault. 0x00000000007565f0 in llvm::MachineJumpTableInfo::getEntrySize(llvm::DataLayout const&) const () (gdb)

Hi Andy, It looks like you're using LLVM's old JIT, rather than MCJIT? The old JIT has been removed from the mainline, and is no longer supported. I'd recommend building your own copy of LLVM from the development branch (as Reed suggested) where MCJIT is used by default - this may fix your issue. If you want to stick with the precompiled binaries, then you should change: #include

In thinking about this we could use a Mutex::tryacquire(...) (non-recursive), around JIT::runJITOnFunctionUnlocked(...)'s while loop, and use your JITEmitter:: getLazyFunctionStub(...) suggestion in place of forceEmitFunctionStub(...). Is the lock attempt too heavy, even if it is implemented with atomics? I'll implement this when I have time. Garrison On Feb 17, 2010, at 15:42, Garrison

Forgot to CC the list. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Trevor Elliott <trevor at galois.com> > Sent: Fri, January 14, 2011 7:33:15 PM > Subject: Re: [LLVMdev] LLVM GC > > Hi Trevor, > > Are you linking with LibStdC++ or LibC++? That is a requirement for running > code that has been compiled from C++

Hi Sam, I've not actually gotten to the linking process with my runtime, as I've compiled it with clang -emit-llvm -c, and then archived it with llvm-ar and llvm-ranlib. I'm also not producing a GC plugin, as I'm using the builtin "shadow-stack" strategy. My current build process looks like this: 1. build the compiler 2. build the runtime using clang -emit-llvm -c

I am trying to JIT some code containing an indirect branch (and the corresponding store i8* blockaddress(@label)). I am using LLVM 2.7 code base. I build the ExecutionEngine using EngineBuilder, and call engine->getPointerToFunction(func). When I use setOptLevel(llvm::CodeGenOpt::None), the JITing fails with the following message : JIT.h:131: virtual void*

Hi, We use LLVM libraries to compile C++ code and noticed slow downs when multiple threads of a process were compiling at once. *perf *indicated that most of the CPU time was spent in a spin lock, which was being locked/unlocked from llvm::PassRegistry::getPassInfo(). We read the relevant LLVM code and found out that PassRegistry is a ManagedStatic and is shared among all threads in case of a

Hello, Platform is RHEL5, GCC 4.2.4, x86-32, and LLVM/LLVM-GCC from subversion (yesterday evening). I'm compiling C code into bitcode, and then executing the bitcode using the JIT compiler (lli). I've managed to reproduce a problem when multiple signals go off around the same time. A sample program is below. The result is the "recursive compilation detected" JIT compiler

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

Hi Olivier, Thanks for responding! I get to learn this way. On Feb 17, 2010, at 12:50, Olivier Meurant wrote: > Hi Garrison, > > I am not a specialist of the code but here is my 2 cents: > > - I like the idea that in lazy-mode the call (in module or not) is treated by a stub (like every calls). If we go further with this, I'll have to add test cases for lazy mode. I kind

Hi James, > want to send us your testcase code? Then we can give it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native