similar to: [LLVMdev] Catching Signals While JIT'ing Code

Right, this gets into the whole error-handling philosophy of LLVM, or lack thereof. The idea is that so long as your frontend generating IR gives correct IR and is well-behaved, LLVM will not assert, abort, or crash. Once you've successfully debugged your frontend, you should never see this kind of error from LLVM and need to recover from it. In practice, this is true enough that it is

Hi all, I have the following C code. static int addp(int *c, int a,int b) { int x = *c + a + b; return(x); } I want to replace *c with a scalar. So I tried the -argpromotion pass. However, it fails to do anything to the resulting llvm file. List of commands: clang add.c -c -o add.bc clang add.c -S -o add.ll opt -argpromotion -stats add.bc -o add_a.bc llvm-dis < add_a.bc > add_a.ll Also,

I am having problems JIT'ing 2 functions where one of them calls the other. (I am using the old JIT interface). Here is the setup: define void @func1() { entrypoint: call void @func2(void) ret void } define void @func2(void) { entrypoint: ret void } (I omit the arguments and function bodies for simplicity.) It's 'func1' that would be called from host code,

I've been profiling more; see <https://dl.dropbox.com/u/46791180/perf.png>. One thing I'm a bit confused about is why I see a FunctionPassManager there. I use a FunctionPassManager at the end of LLVM IR code generation, write the IR to disk, then read it back later. Why is apparently another FunctionPassManager being used during the JIT'ing of the IR code? And how do I

On 4 February 2016 at 22:48, Morten Brodersen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi Rafael, > > Not easily (llc). > > Is there a way to make MCJit not use the large code model when JIT'ing? > I think Davide started adding support for the small code model. Cheers, Rafael

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

On Mar 22, 2012, at 12:28 AM, Bill Wendling wrote: > On Mar 20, 2012, at 7:38 PM, Paul J. Lucas wrote: > >> I've read the docs on LLVM exceptions, but I don't see any examples. A little help? > > I don't think this has anything to do with LLVM's IR-level exception system. It sounds to me like you just need a way to handle C++ exceptions inside of the C++ code

It seems one can only put constant global statements _before_ any functions are defined, not after. I would like to produce eg. "hello world!" functions in a JIT. So I was hoping to use global string constants. Is there another way to do this kind of thing ? thanks, Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940

On Mon, 12 Jun 2006, Simon Burton wrote: > It seems one can only put constant global statements > _before_ any functions are defined, not after. This is true in .ll files, but not necessary in LLVM modules. > I would like to produce eg. "hello world!" functions in a JIT. > So I was hoping to use global string constants. > Is there another way to do this kind of thing ?

On Mon, 12 Jun 2006 12:27:36 -0500 (CDT) Chris Lattner <sabre at nondot.org> wrote: > On Mon, 12 Jun 2006, Simon Burton wrote: > > It seems one can only put constant global statements > > _before_ any functions are defined, not after. > > This is true in .ll files, but not necessary in LLVM modules. Yes, I'm generating .ll files. I'm using a workaround:

I'm not sure I have a clear picture of what you're JIT'ing. If any of the JIT'ed functions call other JIT'ed functions, it may be difficult to find all the dependencies of a functions and recreate them correctly on a subsequent load. Even if the JIT'ed functions only call non-JIT'ed functions, I think you'd need some confidence that the address of the called

Do you have a stack trace of the segfault? We have two different code emitters for X86 in LLVM. The one used by the normal compiler and MCJIT and the other used by the legacy JIT. All of the test cases for AVX support go through the first one so it gets the most attention. We try to keep the legacy JIT in sync with it, but have a history of failing at that. The stack trace of the segfault may

On Mar 20, 2012, at 7:38 PM, Paul J. Lucas wrote: > To recap, on Mar 14, 2012, I wrote: > >> My project has a C++ library that I want to allow the user to use via some programming language to be JIT'd to call functions in said library. For the sake of simplicity, assume the library has classes like: >> >> class item_iterator { >> public: >> virtual

Hello, I recently hit an issue when JIT'ing my generated IR using llvm::orc::LLJIT. My IR contains the following definition of a global variable: > $_ZZ23TestStaticVarInFunctionbE1x = comdat any > @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local global i32 123, > comdat, align 4 > And in my host process, there exists the same symbol. I would expect LLJIT to resolve the

On 9/28/07, Chris Lattner <sabre at nondot.org> wrote: > > > MachineCodeEmitter [3] is obtainable from the JIT class, and it > > contains "BufferBegin", "BufferEnd", and "CurBufferPtr" as protected > > members; if they were available, determining the generated code size > > might be possible via some pointer arithmetic. Is there

On Oct 26, 2012, at 12:59 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > In either case, deleting the ExecutionEngine should result in the JITMemoryManager being deleted and therefore also the memory in which the JITed functions are contained. > > I think it's entirely possible that you just aren't seeing a problem because that memory hasn't been

Is it possible that the AVX support in the JIT engine or x86-64 backend is not mature? I am getting segfaults when switching from a vector length 4 to 8 in my application. I isolated the barfing function and it still segfaults in the minimal setup: The IR attached implements the following simple function: void bar(int start, int end, int ignore , bool add , bool addme , float* out, float* in) {

On Sep 28, 2007, at 10:27 AM, Sandro Magi wrote: > In my quest to account for memory, I've now come to the in-memory IR, > and the generated code. I want to book the generated code memory > against the agent that is generating the code. > > I see that LLVM's Function class [1] has a size function; what does > this represent and can I use it to account for the space used

Thanks for the information I am trying to use one of your examples for recursive data structures: ========================= PATypeHolder StructTy = OpaqueType::get(); std::vector<const Type*> Elts; Elts.push_back(PointerType::get(StructTy)); Elts.push_back(PointerType::get(Type::SByteTy)); StructType *NewSTy = StructType::get(Elts); // At this point, NewSTy = "{ opaque*, sbyte*

Chris Lattner wrote: > On Mon, 6 Dec 2004, Morten Ofstad wrote: >> I guess what I'd like to know is if the process of spilling constants >> to memory could be a bit more controlled, maybe using the JIT memory >> manager and putting it in with the function stubs? > > Yes, this can and should definitely be improved. If you look at >