search for: forceemitfunctionstub

Displaying 11 results from an estimated 11 matches for "forceemitfunctionstub".

2010 Feb 26
2
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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 can instead use a pre-existing method: getPointerT...
2010 Feb 26
1
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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 can instead use a...
2010 Feb 25
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
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 greatly the code of the JIT. If we need to jit 2 d...
2010 Feb 19
3
[LLVMdev] 2nd attempt for a working patch for bug 2606
...to find the function in the known modules. This is the reverse of logic used in #2. On searching, unlike for functions, a linkage check was not made. Also the global variable declaration and 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...
2010 Feb 26
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
...0, 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 can instead use a pre-existing...
2010 Feb 16
2
[LLVMdev] Work in progress patch to bug 2606
...ng to find the function in the known modules. This is the reverse logic used in #2. On searching, unlike for functions, a linkage check was not made. Also the global variable declaration and 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)...
2010 Feb 17
0
[LLVMdev] Work in progress patch to bug 2606
...in the known modules. This is the reverse logic used in #2. On searching, > unlike for functions, a linkage > check was not made. Also the global variable declaration and 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 pat...
2010 Feb 27
2
[LLVMdev] 2nd attempt for a working patch for bug 2606
...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 >>...
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 Venn wrote: > Hi Olivier, > > Thanks for responding! I get to learn this way. > > On Feb 17, 2010, at 12:50, Olivie...
2010 Feb 17
3
[LLVMdev] Work in progress patch to bug 2606
Hi Olivier, Thanks for responding! I get to learn this way. On Feb 17, 2010, at 12:50, Olivier Meurant wrote: > Hi Garrison, > > I am not a specialist of the code but here is my 2 cents: > > - I like the idea that in lazy-mode the call (in module or not) is treated by a stub (like every calls). If we go further with this, I'll have to add test cases for lazy mode. I kind
2010 Mar 01
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
...bly shouldn't go to the trouble of unifying the > types between the modules, so I'd be inclined to just ignore the > types. Or maybe only pay attention when they're concrete types? Ok, I'll modify accordingly if I understand how. > >> 4) The declaration of void* forceEmitFunctionStub(Function *F) was added >> to the class JIT. This is >> implemented in JITEmitter.cpp. > > This isn't quite the right name, but I think you can eliminate it > entirely (see above). Yup > >> Beyond any issues with the patch, there is a question, in my mind, as to...