similar to: ObjectCache and getFunctionAddress issue

Hi, All I m not sure if this question has been asked or not. I'd like cache the MCJIT compiled object into memory buffer so it can be reused later. I followed the Andy Kaylor's example wrote an inherited class from ObjectCache and use raw_fd_ostream to save the cache and load the cache from a file. I checked raw_ostream and its subclass, maybe I am wrong but I don't see one is fit to

In MCJIT, the old JIT functions are deprecated in favor of getFunctionAddress. Code like: llvm::Function *F = M->getFunction(FuncName); void *FN = EE->getPointerToFunction(F); should be rewritten as uint64_t FN = EE->getFunctionAddress(FuncName); While functionally identical, in case the correct module is known the new version will be much slower, linear with the number of added

I should have read this before sending my previous reply. :-) I'm not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Saturday, October 19, 2013 3:17 PM To: Kaylor, Andrew; <llvmdev at cs.uiuc.edu> Subject: An enhancement

The search is linear? If that’s really true, we should fix that. On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I should have read this before sending my previous reply. :-) > > I’m not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. > >

There's probably a lot that we could do, but I can't think of anything easy. Basically every time we need to look up a symbol by name we're going to each module and saying "Do you have this symbol?" It would likely be much better if we grabbed the function names from the module and did the search ourselves so that we could keep some information about the things that

I don’t follow. Why are we looking at the module at all? That query should work even (especially) after the Module is deleted. We should be able to have a local symbol table that’s a DenseMap or something similar to resolve from names to target addresses. That map would be updated as part of the compilation when the object’s symbol table gets read. -Jim On Oct 21, 2013, at 4:55 PM, Kaylor,

Hi Jim, Clearly searching for name should not be linear in modules but with a map of some kind. After compilation to IR each module has a StringMap symbol table. After compiling to MC and loading the object file, the dynamic linker has a StringMap symbol table for all loaded modules. In the usual use case you'll load module(s) into MCJIT and then compile / link them and all is well, no

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

This segfault occuring only under valgrind, in shell way, and in gdb way i have Invalid bitcode signature simple_scev_dynamic_array: /home/willy/apollo/llvm/include/llvm/Support/ErrorOr.h:258: storage_type *llvm::ErrorOr<llvm::Module *>::getStorage() [T = llvm::Module *]: Assertion `!HasError && "Cannot get value when an error exists!"' failed. Command terminated by

Hello Willy, Here is the dump from one of my bitcode files: 0000000 42 43 c0 de 21 0c 00 00 25 05 00 00 0b 82 20 00 As expected, 0x42 (= B), 0x43 (= C), xc0 and 0xde are in correct order. In your case, the first byte is read as 37 (= 0x25). I wonder why? When you check the bytes yourself, you get expected results. When the same bytes are read from Stream object, you get a different result (maybe

Hi all, I'm trying to play with patchoint (with MCJIT and VMKit) and I don't understand something. I generate this call for my first patch point. Basically, I want to call f(0). %5 = call i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64( i64 42, ;; patch point id is 42 i32 0, ;; 0 bytes for the padding i8* bitcast (i32 (i32)* @f to i8*), ;; my function f i32 1,

all of: ---- // cout << "lsr: " << lsr << "\n"; llvm::MemoryBuffer* mbjit = llvm::MemoryBuffer::getMemBufferCopy (sr); ------ string lsr = sr.str(); // cout << "lsr: " << lsr << "\n";

patchpoint is intended to be used in VMs that do their own linking, and so you wouldn't expect the function parameter to be resolved by LLVM. Presumably, in VMKit, you could just plant a pointer constant to the function you wish to call initially? -Filip On Dec 17, 2013, at 2:42 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Hi all, > > I'm trying to play with

So I've made code to invoke the getfunctionaddress() in parallel. I did verify that the code was good, by substituting getfunctionaddress() with a bunch bogus computations. It seems that the code with getfunctionaddress() is being serialized. Is there a giant lock somewhere per executionengine? I have one execution engine that holds all the modules. Going through the llvm-dev list archives,

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could

> On Dec 20, 2016, at 9:13 AM, koffie drinker via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I'm trying to speed up the JIT time with llvm (3.9.1). > So far i've implemented the object cache, used FastISel and disabled optimizations. I can’t help with the rest, but just wanted to mention that totally disabling the IR optimizations is not necessarily

Hi, I'm trying to speed up the JIT time with llvm (3.9.1). So far i've implemented the object cache, used FastISel and disabled optimizations. Jit time is still too slow for my purpose (I do have a lot of code to Jit). http://llvm.org/docs/ProgrammersManual.html#threads-and-the-jit states that we can invoke ExecutionEngine::getPointerToFunction() concurrently. This function was replaced

Hi, All I have a problem to reuse mcjit jitted code loaded from ObjectCache from a file. In the first run, I use MCJIT generate function JittedOpExpr object code as following and it runs OK. 0x7fe4801fa1f8 at instruction 0x00007fe4cc6c2014 points to 0x69382E which is the beginning of ExecEvalVar function. Then I save the object code into a file after implementing notifyObjectCompiled method.

Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return