search for: jitresolve

Displaying 20 results from an estimated 40 matches for "jitresolve".

Did you mean: jitresolver
2005 Apr 21
2
[LLVMdev] Control Flow and Locks when JITing Functions
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 t...
2005 Apr 21
0
[LLVMdev] Control Flow and Locks when JITing Functions
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'...
2010 Feb 16
2
[LLVMdev] Work in progress patch to bug 2606
...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 JITRes...
2010 Feb 07
3
[LLVMdev] Jit singleton
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...
2010 Feb 10
0
[LLVMdev] Jit singleton
...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...
2010 Feb 04
0
[LLVMdev] Jit singleton
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...
2010 Feb 10
1
[LLVMdev] Jit singleton
...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... &...
2010 Feb 26
2
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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 promp...
2010 Feb 04
2
[LLVMdev] Jit singleton
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
2010 Feb 26
1
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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 sco...
2005 Feb 20
3
[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X
.../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 0...
2010 Feb 17
0
[LLVMdev] Work in progress patch to bug 2606
...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 p...
2010 Feb 17
0
[LLVMdev] Work in progress patch to bug 2606
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
2010 Feb 26
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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). ......
2008 Jun 16
0
[LLVMdev] PowerPC instruction cache invalidation
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!
2008 Jun 17
1
[LLVMdev] PowerPC instruction cache invalidation
...; 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...
2004 Sep 29
4
[LLVMdev] LLVM build error (sparc gcc 3.2.2)
...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 ... ------...
2005 Feb 20
0
[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X
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...
2010 Feb 19
3
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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...
2010 Feb 25
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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...