search for: getpointertoglobalifavailable

Hi Gabi, I have no idea why your performances is not as expected with such low level of informations. But, I know that the binary code is cached by the JIT. You can find the code in JIT.cpp to convince yourself : runFunction -> getPointerToFunction ->getPointerToGlobalIfAvailable which returns the native address of the jitted function. You can even try to measure time needed by each runFunction to run to double-convince yourself. :) Olivier. On Thu, Mar 18, 2010 at 9:21 AM, Gabi <bugspynet at gmail.com> wrote: > Hello > I have the following scenario, and I...

Hello I have the following scenario, and I am not sure why the performance is so bad (take 30 minutes to complete with very simple generated functions): 1. Create module 2. Do something like EE = EngineBuilder(theModule).setEngineKind(EngineKind::JIT).create(); 3. Create a function in the module: theModule->getOrInsertFunction(..) 4. Execute 1000 times the function using

...tub(...) which is declared in ExecutionEngine and overwritten in JIT (within JITEmitter file scope). Your response prompted my search. I've unit tested this and it works great. There is one caveat though. The implementation of JIT::getPointerToFunctionOrStub(...) first invokes ExecutionEngine::getPointerToGlobalIfAvailable(...) behavior to check whether or not the Function instance is already actualized. Subsequently JIT::getPointerToFunctionOrStub(...) calls JITResolver::getLazyFunctionStub(...). Given that ExecutionEngine::getPointerToGlobalIfAvailable(...) iterates through all known actualized functions, we wou...

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

...oreMemory(F); > -    return true; > +         for (unsigned i = 0, e = BackupRelocations.size(); i != e; ++i) { > +                 MachineRelocation &MR = BackupRelocations[i]; > +                 if (MR.isGlobalValue()) { > +                         void* ResultPtr = TheJIT->getPointerToGlobalIfAvailable(MR.getGlobalValue()); > +                         if (BufferBegin <= ResultPtr && ResultPtr < BufferEnd) { > +                                 TheJIT->updateGlobalMapping(MR.getGlobalValue(), 0); > +                         } > +                 } > +         } >...

This is the second version of a patch, which I recently attached to bug 2606, whose original version was modified to reflect the lists comments. Also please note the comment at the end of this email, which basically questions whether this bug is really a bug. 1) To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello! Working with LLVM JIT-compiler I found a small bug and I'd like to correct it. Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" This error emerges because the test creates big static array. Global variables are placed into memory block for function, that is first seen using given variable. Besides, during memory allocation

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached