search for: getlazyfunctionstub

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 Venn wrote: > Hi Olivier, > > Thanks for responding! I get to learn this...

...ch. > > - If the jit is in non-lazy mode, I'm not really fan of the "stub" solution. Is it not possible to use the same mechanism as it already exists : add the function to pending list and emit it after the current functions ? In fact, can you replace forEmitFunctionStub with getLazyFunctionStub ? With a non-lazy jit, I want the first execution of my function to be the same execution speed as the second one. A stub in non-lazy mode doesn't fell natural to me. So as best as I can determine, the problem with leveraging pending, as used by getLazyFunctionStub(...) is that I don't kn...

....com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take time to watch your 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 > n...

Hi Olivier, On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > Hi Garrison, > > I finally come back from holidays and take time to watch your 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...

...; Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > >> Hi Garrison, >> >> I finally come back from holidays and take time to watch your 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 s...

Hi Garrison, I finally come back from holidays and take time to watch your 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 ? I thought about JIT and modules, and I wonder if we don't need to take it another way. Now we can create multiples JIT. What if we decide to simplify the JIT in allowing only one module per instance of JIT ? It will simplify...

...every calls). - If the jit is in non-lazy mode, I'm not really fan of the "stub" solution. Is it not possible to use the same mechanism as it already exists : add the function to pending list and emit it after the current functions ? In fact, can you replace forEmitFunctionStub with getLazyFunctionStub ? With a non-lazy jit, I want the first execution of my function to be the same execution speed as the second one. A stub in non-lazy mode doesn't fell natural to me. - I don't see why functions external to every modules (let's say "printf" ?) are delayed with your mechanism....

...st 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 grained in their appro...

...) 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 JITResolver::JITCompilerFn(...) for runtime emission that the lazy compilation system uses. Outside of the goal, I'm not sure what code is unnecessary here. Notice that the hasAvailableExternallyLinkage case is dealt with here even tho...

...vier, >> On Feb 25, 2010, at 14:10, Olivier Meurant wrote: >> >> Hi Garrison, >> >> I finally come back from holidays and take time to watch your 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 &...

...= dyn_cast<GlobalAlias>(V)) { + Function *F = const_cast<Function*>(dyn_cast<Function>(GA->resolveAliasedGlobal(false))); + if (F == NULL) { + return TheJIT->getPointerToGlobal(GA->resolveAliasedGlobal(false)); + } else { + void *FnStub = Resolver.getLazyFunctionStubIfAvailable(F); + if (FnStub) + return FnStub; + else + return Resolver.getLazyFunctionStub(F); + } + } + // If we have already compiled the function, return a pointer to its body. Function *F = cast<Function>(V); Attached is the patch. I am not sure it is the...