similar to: [LLVMdev] Are multiple execution engines allowed?

> That's me (and I'm not on IRC because I like messages to be > archived).  The reason everything needs to go in the same buffer is > that we're JITting code on one machine, then sending it to another to > be executed, and references from one buffer to another won't work in > that environment.  So that model needs to continue to work.  If you > want to generalize

Bill, That is great to hear. I must be doing something wrong. When I try to do this, I get ERROR: Program used external function 'myLinkedFunction' which could not be resolved! Because of its brevity, I use getOrInsertFunction when I am creating calls to the function in module A. I use new llvm::Function(type, llvm::Function::ExternalLinkage, "myLinkedFunction", moduleB)

Hi Evan, Thanks a lot for the information! It's a viable solution to write my own JITMemoryManager, however I noticed that the JIT doesn't know the length of the binary function before it is actually emitted. This is a bit inconvenient especially since I have to generate new functions at irregular times. I'm not too keen on using the non-standard _expand function to resize

This is what I was trying to do when I ran into the HowToUseJIT problem. I've made a first attempt at adding locking to the JIT. Unfortunately, since I do not really understand the structure of LLVM, I could have very easily screwed something up. I touched two classes, the JIT and the ExecutionEngine. I need some help from someone who is more familiar with the code to make sure that I

On Mon, Jun 29, 2009 at 9:23 PM, Reid Kleckner<rnk at mit.edu> wrote: >> That's me (and I'm not on IRC because I like messages to be >> archived).  The reason everything needs to go in the same buffer is >> that we're JITting code on one machine, then sending it to another to >> be executed, and references from one buffer to another won't work in

When JITEmitter is teared down, it also deletes the JITMemoryManager instance. That in turns release the memory of the generated functions. Is this what you are referring to? The DefaultJITMemoryManager is pretty simple. You can obviously write your own memory manager class that maps the memory in a way that's persistent. Then all you have to do is to pass a handle of it to

Hi all, I'm using LLVM to generate a fairly large number of separate functions at run-time. To minimize the memory overhead, I'd like to delete the IR and everything else that is no longer needed after a function has been generated (I don't use lazy compilation or anything like that). I noticed that deleting the ExecutionEngine deletes everything (Module, Function(s),

On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > So I (think I) found a bug in the JIT: > http://llvm.org/bugs/show_bug.cgi?id=4483 > > Basically, globals used by a function are allocated in the same buffer > as the first code that uses it. However, when you free the machine > code, you also free the memory holding the global's data. The address > is still in the

So I (think I) found a bug in the JIT: http://llvm.org/bugs/show_bug.cgi?id=4483 Basically, globals used by a function are allocated in the same buffer as the first code that uses it. However, when you free the machine code, you also free the memory holding the global's data. The address is still in the GlobalValue map, so any other code using that global will access freed memory, which

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking

Signed-off-by: Scott Seago <sseago at redhat.com> --- AUTHORS | 17 ++++++ README | 10 +++ conf/ovirt-agent | 12 ++++ conf/ovirt-db-omatic | 12 ++++ conf/ovirt-host-browser | 12 ++++