similar to: [LLVMdev] Change optimization level during compilation

Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options

Hi Andrew, I used the latest code from trunk. GlobalSymbolTable is being used in MCJIT. I guess it wasn't clear from the proposal that the user program will be modified to indicate that the callback should happen at that point in the code. The objective is to call some of the functions which belong to lli or the ExecutionEngine. Thanks, Sumeeth On Fri, Nov 1, 2013 at 5:40 PM, Kaylor,

On Thu, Oct 31, 2013 at 11:39 PM, sumeeth kc <sumeethkc at gmail.com> wrote: > Hello, > > I would like to have your opinions on this. > > *Problem:* > > Currently, there are no ways to perform hypercalls into LLVM (they > transfer execution from the program being executed to the LLVM > infrastructure to perform compilation). The goal of this project is to >

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

Hi all, I am new to LLVM so I apologize if my question seem lame to you. I was trying to understand the way in which MCJIT generates the stub functions when it encounters any functions which are not compiled yet. As far as I have looked into the code, the probable code which can do this is void *JIT::getPointerToFunctionOrStub and this is in JITEmitter under JIT. I may be wrong here though.

Hi Sumeeth, I'm not sure I understand what your new mechanism is supposed to add. You can already call functions defined in the host program from generated code. The Kaleidoscope tutorial does this. If the function you want to call is defined in a module that is dynamically loaded and you are using the default memory manager all you need to do is declare a prototype for the function in

Hello, I would like to have your opinions on this. *Problem:* Currently, there are no ways to perform hypercalls into LLVM (they transfer execution from the program being executed to the LLVM infrastructure to perform compilation). The goal of this project is to cleanly integrate an API into the LLVM code/execution engine to create custom callbacks. The “lli” executable should allow having a

On Aug 5, 2011, at 10:57 AM, Peter Lawrence wrote: > However it seems that if a landingpad-block has multiple predecessors (often the case, > multiple InvokeInst in the main body of a try-statement all go to the same landingpad- > block), then you cannot move the LandingpadInst in order to break a critical edge unless > you do it for _all_ landingpad-block predecessor edges

Are you using the latest code from trunk? I didn't think the latest code used the address mapping in the ExecutionEngine base class. Of course, if people are depending on this it might be something that should be fixed if it isn't working. -Andy From: Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com] Sent: Friday, November 01, 2013 10:54 AM To: Kaylor, Andrew; sumeeth kc;

On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote: > > ----- "Evan Cheng" <evan.cheng at apple.com> wrote: > >> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: >> >>> Evan, >>> So, if I understand you correctly, the design you have in mind is >>> to: create a PassManager, pass it to the JIT on construction, and >>>

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

Hey Everyone, I understood this a little differently (well, I do have direct contact with Sumeeth given that we both work in the same lab). Allow me to try and explain his proposal. We are trying to optimise out instructions from a program (JIT-compiled OS Kernels or JIT-compiled Web Server code) during run time and we have this hypothesis that some of the decisions are best taken by the

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

When a whole-file checksum is performed, hashing was done in 64 byte blocks, causing overhead and limiting performance. Testing showed the performance improvement to go up quickly going from 64 to 512 bytes, with diminishing returns above, 4096 was where it seemed to plateau for me. Re-used CHUNK_SIZE (32 kB) as it already exists and should be fine to use here anyway. Noticed this because

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

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'm trying to figure out the best way to handle signals raised during the execution of LLVM's optimization passes or the JIT'ing of code prior to running it. In particular, LLVM throws unix signals instead of C++ exceptions while the header ErrorHandling.h contains the following warning (the last paragraph in particular): /// llvm_instal_error_handler - Installs a new error handler

On Wed, Jul 25, 2012 at 12:24 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Following up and expanding on an earlier conversation, I'd like to discuss > making several non-trivial changes to the MCJIT engine and related objects. I would like to take part in this discussion (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/052022.html) but there are still subjects

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Kaylor, Andrew > Subject: Re: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines > If the function is in a statically linked module, you need to do something to explicitly expose it. With > the older JIT engine you can use addGlobalMapping as Yaron suggests, but I

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