search for: thejitresolver

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static DenseMap<stub_address, JITResolver*> instead, or 2) include the JITResolver* inside the stub as an argument to the compilation callback. Nobody's needed this enough to get it working though. I think it'd...

...ager compilation mode, I don't know of anything that would go > wrong with having multiple JITs in the process. However, in lazy > compilation mode, we need to map stub addresses to the JIT that knows > how to compile them. Right now, that's done by looking up the static > "TheJITResolver" variable and assuming it's the only JIT, but we could > 1) use a static DenseMap<stub_address, JITResolver*> instead, or 2) > include the JITResolver* inside the stub as an argument to the > compilation callback. Nobody's needed this enough to get it working > though...

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

...mode, I don't know of anything that would go >> wrong with having multiple JITs in the process. However, in lazy >> compilation mode, we need to map stub addresses to the JIT that knows >> how to compile them. Right now, that's done by looking up the static >> "TheJITResolver" variable and assuming it's the only JIT, but we could >> 1) use a static DenseMap<stub_address, JITResolver*> instead, or 2) >> include the JITResolver* inside the stub as an argument to the >> compilation callback. Nobody's needed this enough to get it working...

...now of anything that would go > >> wrong with having multiple JITs in the process. However, in lazy > >> compilation mode, we need to map stub addresses to the JIT that knows > >> how to compile them. Right now, that's done by looking up the static > >> "TheJITResolver" variable and assuming it's the only JIT, but we could > >> 1) use a static DenseMap<stub_address, JITResolver*> instead, or 2) > >> include the JITResolver* inside the stub as an argument to the > >> compilation callback. Nobody's needed this enough to...

On Mon, 16 Jun 2008, Gary Benson wrote: > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. Applied, thanks!

...tionStub(F); } Index: lib/ExecutionEngine/JIT/JITEmitter.cpp =================================================================== --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 52391) +++ lib/ExecutionEngine/JIT/JITEmitter.cpp (working copy) @@ -145,20 +145,6 @@ JITResolver *JITResolver::TheJITResolver = 0; -#if (defined(__POWERPC__) || defined (__ppc__) || defined(_POWER)) && \ - defined(__APPLE__) -extern "C" void sys_icache_invalidate(const void *Addr, size_t len); -#endif - -/// synchronizeICache - On some targets, the JIT emitted code must be -/// explicitly refetched...

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can