search for: jitresolver

I just located a concurrency error in my LLVM patch to add locks to the JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp, which clearly is a problem since This particular issue causes an assertion failure on occasion when running a task that spawns threads on a parallel machine. Any recommendations about if I am doing something that seems horribly wrong are welcome. I'll update my patch th...

On Thu, 21 Apr 2005, Evan Jones wrote: > I just located a concurrency error in my LLVM patch to add locks to the > JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp, > which clearly is a problem since This particular issue causes an > assertion failure on occasion when running a task that spawns threads on > a parallel machine. Any recommendations about if I am doing something > that seems horribly wrong are welcome. I'l...

...definition must have the exact same type. Is this the correct approach? 4) The declaration of void* forceEmitFunctionStub(Function *F) was added to the class JIT. This is implemented in JITEmitter.cpp. JITEmitter.cpp: 1) JIT::forceEmitFunctionStub(...) was added. It turns around and calls JITResolver::forceEmitFunctionStub(...). Is the JIT:getPointerToFunction(...) code path sensitive to such call overhead? 2) JITResolver::forceEmitFunctionStub(Function *F) was added. It is a simplified version of JITResolver::getLazyFunctionStub(...), which does not add to pending. It uses the same JITReso...

Hi Jeffrey, Thanks for pointing me in the right direction ! I'm not using the JIT in lazy mode, but it was fun to understand the lazy-stub code. Attached you will find a patch which follow your 1st option : a map Stub_address -> JITResolver instance, except that the used map is a "std::map" to apply the same upper_bound trick as in the map CallSiteToFunctionMap of the ResolverState. (If it is necessary for call_site -> function, this should be necessary for call_site -> resolver... Event if I'm not sure to master a...

...at gmail.com> wrote: > Hi Jeffrey, > > Thanks for pointing me in the right direction ! > I'm not using the JIT in lazy mode, but it was fun to understand the > lazy-stub code. > > Attached you will find a patch which follow your 1st option : a map > Stub_address -> JITResolver instance, except that the used map is a > "std::map" to apply the same upper_bound trick as in the map > CallSiteToFunctionMap of the ResolverState. (If it is necessary for > call_site -> function, this should be necessary for call_site -> resolver... > Event if I'm...

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

...frey, > > > > Thanks for pointing me in the right direction ! > > I'm not using the JIT in lazy mode, but it was fun to understand the > > lazy-stub code. > > > > Attached you will find a patch which follow your 1st option : a map > > Stub_address -> JITResolver instance, except that the used map is a > > "std::map" to apply the same upper_bound trick as in the map > > CallSiteToFunctionMap of the ResolverState. (If it is necessary for > > call_site -> function, this should be necessary for call_site -> > resolver... &g...

...patch. > > I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? JIT::forceEmitFunctionStub(...) was created to bring its implementation into JITEmitter file scope as JITResolver and therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous namespace in that scope. However I can instead use a pre-existing method: getPointerToFunctionOrStub(...) which is declared in ExecutionEngine and overwritten in JIT (within JITEmitter file scope). Your response prompt...

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

...that I largely prefer this version over the previous one ! I > like the reuse of getLazyFunctionStub, but I don't know if the > forceEmitFunctionStub is still needed ? > > > JIT::forceEmitFunctionStub(...) was created to bring its implementation > into JITEmitter file scope as JITResolver and > therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous > namespace in that scope. However > I can instead use a pre-existing method: getPointerToFunctionOrStub(...) > which is declared in ExecutionEngine > and overwritten in JIT (within JITEmitter file scop...

.../llvm/include/llvm/ADT/ilist:440 #3 0x00011ae8 in llvm::JIT::runJITOnFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:217 #4 0x00011da4 in llvm::JIT::getPointerToFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:261 #5 0x000123e4 in (anonymous namespace)::JITResolver::getFunctionStub(llvm::Function*) (this=0x70be78, F=0x5101010) at JITEmitter.cpp:184 #6 0x00012a48 in (anonymous namespace)::JITEmitter::getPointerToGlobal(llvm::GlobalValue*, void*, bool) (this=0x5101670, V=0x5101010, Reference=0x5685010, DoesntNeedStub=false) at JITEmitter.cpp:334 #7 0x...

...gt; Is this the correct approach? > > 4) The declaration of void* forceEmitFunctionStub(Function *F) was added > to the class JIT. This is > implemented in JITEmitter.cpp. > > JITEmitter.cpp: > > 1) JIT::forceEmitFunctionStub(...) was added. It turns around and calls > JITResolver::forceEmitFunctionStub(...). > > Is the JIT:getPointerToFunction(...) code path sensitive to such call > overhead? > > 2) JITResolver::forceEmitFunctionStub(Function *F) was added. It is a > simplified version of JITResolver::getLazyFunctionStub(...), > which does not add to pe...

In thinking about this we could use a Mutex::tryacquire(...) (non-recursive), around JIT::runJITOnFunctionUnlocked(...)'s while loop, and use your JITEmitter:: getLazyFunctionStub(...) suggestion in place of forceEmitFunctionStub(...). Is the lock attempt too heavy, even if it is implemented with atomics? I'll implement this when I have time. Garrison On Feb 17, 2010, at 15:42, Garrison

...gt;> I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? > > JIT::forceEmitFunctionStub(...) was created to bring its implementation into JITEmitter file scope as JITResolver and > therefore JITResolver::getLazyFunctionStub(...) are members of an anonymous namespace in that scope. However > I can instead use a pre-existing method: getPointerToFunctionOrStub(...) which is declared in ExecutionEngine > and overwritten in JIT (within JITEmitter file scope). ... &...

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!

...; return MCE.finishFunctionStub(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...

...errors when I tried to build LLVM. The tar file is llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2. ------------- Compiling SparcV9CodeEmitter.cpp /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In static member function `static void llvm::<unnamed>::JITResolver::CompilationCallback()': /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp:340: warning: cast to pointer from integer of different size /usr/ccs/bin/as: "/var/tmp//ccFz2VBS.s", line 3147: error: cannot use v8plus registers in a non-v8plus target binary ... -------...

On Feb 20, 2005, at 11:12, Evan Jones wrote: > I can "fix" it by changing JITResolver::getFunctionStub to use > F->isExternal() instead of F->hasExternalLinkage(). However, this then > breaks when calling *real* external functions (native code). I obviously should not post to mailing lists before I've eaten. With my "fix" I get an assertion when taking...

...definition must have the exact same type. Is this the correct approach? 4) The declaration of void* forceEmitFunctionStub(Function *F) was added to the class JIT. This is implemented in JITEmitter.cpp. JITEmitter.cpp: 1) JIT::forceEmitFunctionStub(...) was added. It turns around and calls JITResolver::getLazyFunctionStub(...) which emits the foreign function as a stub. Beyond any issues with the patch, there is a question, in my mind, as to whether 2606 is really a bug. Sure its resolution makes using the JIT simpler for cross module behavior, but current manual solutions may be more fined g...

...pe. > Is this the correct approach? > > 4) The declaration of void* forceEmitFunctionStub(Function *F) was added > to the class JIT. This is > implemented in JITEmitter.cpp. > > JITEmitter.cpp: > > 1) JIT::forceEmitFunctionStub(...) was added. It turns around and calls JITResolver::getLazyFunctionStub(...) > which > emits the foreign function as a stub. > > Beyond any issues with the patch, there is a question, in my mind, as to > whether 2606 <http://llvm.org/bugs/show_bug.cgi?id=2606> is really a bug. > Sure its resolution makes > using the JIT s...