search for: objectcach

Yes, exactly. My patch adds a new ObjectCache class which can be registered with MCJIT. MCJIT will then call this component before attempting to generate code to see if it has a cached object image for a given module. If the ObjectCache has a cached object, MCJIT will skip the code generation step and just perform linking and loading. If t...

On Tue, Apr 23, 2013 at 10:39 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Hi Dmitri, > > Regarding your first question, if you can use the MCJIT engine a caching > mechanism will be available very soon. I'm preparing to commit a patch > today to add this capability. I'm not sure what it would take to get > something similar working with the older JIT

Hello, I am a bit curious about the rationale for the current callback-based object cache API. For Numba, it would be easier if there would be a simple procedural API: - one method to get a module's compiled object code - one method to load/instantiate a module from a given piece of object code I manage to get around the callback-based API to do what I want, but it's a bit weird to work

...it work on Windows as well ? I considered MCJIT for my work, but was not sure if there are any features supported by old JIT but missing in MCJIT. Thanks, Dmitri Am 23.04.2013 20:26 schrieb "Kaylor, Andrew" <andrew.kaylor at intel.com>: > Yes, exactly. My patch adds a new ObjectCache class which can be > registered with MCJIT. MCJIT will then call this component before > attempting to generate code to see if it has a cached object image for a > given module. If the ObjectCache has a cached object, MCJIT will skip the > code generation step and just perform linkin...

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

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 save to memory buffer. Any suggestions? Thank you very much -- Best regards Cheng -------------- next part -------------- An HTML...

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 notifyOb...

Hi all, I'm trying to add pre-compiled object cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id = M->getModuleIdentifier(); auto iter = CachedObjs.find(id);...

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing, and compiling my runtime and directly linking it with the rest of the compiler, and then tying together references in the jit modules to e...

...would be helpful if you could attach the object that was stored in your > cache. > > Cheers, > Lang. > > On Thu, Sep 11, 2014 at 10:58 AM, Cheng Zhu <chengzhu at gmail.com> wrote: > >> 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 int...

Hi Gaël, I would guess that MCJIT is probably attempting to load and link the shared library you return from the ObjectCache in the way it would load and link generated code, which would be wrong for a shared library. I know it seems like it should be easier to handle a shared library than a raw relocatable object (and it probably is) but MCJIT doesn't handle that case at the moment. The ObjectCache interface expe...

...Maybe that I have to implement my own Dyld to retrieve the external symbol? Thank you again :) Gaël 2013/11/18 Kaylor, Andrew <andrew.kaylor at intel.com>: > Hi Gaël, > > I would guess that MCJIT is probably attempting to load and link the shared library you return from the ObjectCache in the way it would load and link generated code, which would be wrong for a shared library. I know it seems like it should be easier to handle a shared library than a raw relocatable object (and it probably is) but MCJIT doesn't handle that case at the moment. The ObjectCache interface expe...

...Maybe that I have to implement my own Dyld to retrieve the external symbol? Thank you again :) Gaël 2013/11/18 Kaylor, Andrew <andrew.kaylor at intel.com>: > Hi Gaël, > > I would guess that MCJIT is probably attempting to load and link the shared library you return from the ObjectCache in the way it would load and link generated code, which would be wrong for a shared library. I know it seems like it should be easier to handle a shared library than a raw relocatable object (and it probably is) but MCJIT doesn't handle that case at the moment. The ObjectCache interface expe...

Hump, I think that I have to solution, but I have a new problem (more serious). For the solution, it's stupid, I have simply loaded the shared library in ObjectCache::getObject directly in a MemoryBuffer :) As the linker understand a .o, it understands a .so. Now, I'm able to compile a module (I call finalizeObject()), I'm able to find my first generated function pointer, but I'm unable to execute it. The code is correct (the same as with the old...

...tarted 20:25:26 Starting services Replacing service 'machoNet' with 'eveMachoNet' Service machoNet: 0.001s Replacing service 'dataconfig' with 'eveDataconfig' Service dataconfig: 0.008s Replacing service 'photo' with 'evePhoto' Replacing service 'objectCaching' with 'eveObjectCaching' Service objectCaching: 0.000s Replacing service 'browserHostManager' with 'eveBrowserHostManager' Replacing service 'calendar' with 'eveCalendar' Service addressbook: 0.000s Service counter: 0.000s Service clientStatsSvc: 0.000...

...ile. I then embed this as a binary blob into my executable, and call ParseBitcodeFile on it at startup. Unfortunately, this parsing takes about 60ms right now, which is the main component of my ~100ms time to run on an empty source file (another ~20ms is loading the pre-jit'd image through an ObjectCache). I thought I'd save some time by using getLazyBitcodeModule, since the IR isn't actually needed right away, but this only reduced the parsing time (ie the time of the actual getLazyBitcodeModule() call) to 45ms, which I thought was surprising. I also tested computing the bytewise-xor of...

...ins all the needed functions at runtime and, as they are also compiled the VMKit binary binary, we manually associate the llvm function names to their physical address through an addGlobalMapping with a dlsym. If I understand correctly, MCJIt does not like this solution because it tries to find an ObjectCache that contains the symbol? And I don't see how I can perform something similar with an ObjectCache? Of course, I would like to avoid a recompilation of the runtime functions during the bootstrap because, to simplify the process of generating the bitcode of the runtime functions, I simply reload...

...er, and (2) the bits you're dumping are *exactly* the bits flowing into the JIT linker: there is no chance of getting misleading assembly due to a compiler misconfiguration or persistent state bug. One way to dump object files, which works for both LLJIT and custom stacks, is to attach a dummy ObjectCache (see https://github.com/llvm/llvm-project/blob/master/llvm/examples/LLJITExamples/LLJITWithObjectCache/LLJITWithObjectCache.cpp) and dump the ObjBuffers that are passed in to the cache to disk. You can just return 'nullptr' from your dummy cache's getObject method, since you are not re...

...started 9:43:37 Starting services Replacing service 'machoNet' with 'eveMachoNet' Service machoNet: 0.001s Replacing service 'dataconfig' with 'eveDataconfig' Service dataconfig: 0.015s Replacing service 'photo' with 'evePhoto' Replacing service 'objectCaching' with 'eveObjectCaching' Service objectCaching: 0.000s Replacing service 'browserHostManager' with 'eveBrowserHostManager' Replacing service 'calendar' with 'eveCalendar' Service addressbook: 0.000s Service counter: 0.000s Service clientStatsSvc: 0.000...

...as a binary > blob into my executable, and call ParseBitcodeFile on it at startup. > > Unfortunately, this parsing takes about 60ms right now, which is the main > component of my ~100ms time to run on an empty source file (another ~20ms > is loading the pre-jit'd image through an ObjectCache). I thought I'd save > some time by using getLazyBitcodeModule, since the IR isn't actually needed > right away, but this only reduced the parsing time (ie the time of the > actual getLazyBitcodeModule() call) to 45ms, which I thought was > surprising. I also tested computing...