Thanks Jeffrey !<br><br>If possible, keep me inform (on revision number), I'm interested to see how you will do the unit test. (For my future patch... :) ). <br><br>Thanks again.<br>Olivier.<br><br><br><div class="gmail_quote">
On Wed, Feb 10, 2010 at 6:22 PM, Jeffrey Yasskin <span dir="ltr"><<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks for the patch! I'll clean this up, convert your sample to a<br>
unit test, and commit it for 2.7.<br>
<br>
On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant<br>
<div><div></div><div class="h5"><<a href="mailto:meurant.olivier@gmail.com">meurant.olivier@gmail.com</a>> wrote:<br>
> Hi Jeffrey,<br>
><br>
> Thanks for pointing me in the right direction !<br>
> I'm not using the JIT in lazy mode, but it was fun to understand the<br>
> lazy-stub code.<br>
><br>
> Attached you will find a patch which follow your 1st option : a map<br>
> Stub_address -> JITResolver instance, except that the used map is a<br>
> "std::map" to apply the same upper_bound trick as in the map<br>
> CallSiteToFunctionMap of the ResolverState. (If it is necessary for<br>
> call_site -> function, this should be necessary for call_site -> resolver...<br>
> Event if I'm not sure to master all subtle reasons - code alignment/prologue<br>
> ?)<br>
> A mutex on the StubToResolverMap should prevent any possible race<br>
> conditions.<br>
><br>
> Every object (Emitter, Resolver, ResolverState) have now a private member<br>
> instance of JIT (JIT *Jit).<br>
><br>
> The bugpoint tool is using a extern 'C' function :<br>
> "getPointerToNamedFunction" to get native pointer on function. This function<br>
> used the TheJit static pointer. To keep alive this functionality, I have<br>
> added a static SmallVector<JIT*> JitPool (with its mutex JitPoolLock), which<br>
> keep pointers of available JIT instance. A new static method on JIT object<br>
> "getPointerToNamedFunctionOnJitPool" fills the need (iterate over available<br>
> JIT to find the function).<br>
><br>
> Attached you will find a test, based on "HowToUseJit" example, which<br>
> instantiate 2 JIT, in eager/lazy mode and retrieve native pointer via<br>
> getPointerToNamedFunction function. Where does it belong ? Should I add<br>
> something to llvm test suite ? To the test directory ?<br>
><br>
> Let me know what you think !<br>
> Thanks.<br>
><br>
> Olivier.<br>
><br>
> On Thu, Feb 4, 2010 at 9:03 PM, Jeffrey Yasskin <<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>> wrote:<br>
>><br>
>> In eager compilation mode, I don't know of anything that would go<br>
>> wrong with having multiple JITs in the process. However, in lazy<br>
>> compilation mode, we need to map stub addresses to the JIT that knows<br>
>> how to compile them. Right now, that's done by looking up the static<br>
>> "TheJITResolver" variable and assuming it's the only JIT, but we could<br>
>> 1) use a static DenseMap<stub_address, JITResolver*> instead, or 2)<br>
>> include the JITResolver* inside the stub as an argument to the<br>
>> compilation callback. Nobody's needed this enough to get it working<br>
>> though.<br>
>><br>
>> I think it'd make some sense to fix it for eager compilation even<br>
>> before getting lazy compilation working. Would you like to write a<br>
>> patch? You'll have to remove all uses of TheJIT and TheJITResolver<br>
>> except for the one in JITResolver::JITCompilerFn, and change the "only<br>
>> one JIT" check to say something about "only one JIT compiling lazily".<br>
>><br>
>> I don't think this change will require passing an LLVMContext to the<br>
>> JIT--it should just use the Context of the function it's jitting.<br>
>><br>
>> The code freeze for llvm-2.7 is on Feb 21 (this probably isn't a<br>
>> "major" change), so if you want it in the 2.7 release, please try to<br>
>> mail the patch well ahead of that.<br>
>><br>
>> On Thu, Feb 4, 2010 at 5:47 AM, Olivier Meurant<br>
>> <<a href="mailto:meurant.olivier@gmail.com">meurant.olivier@gmail.com</a>> wrote:<br>
>> > Hi everyone !<br>
>> ><br>
>> > If I call ExecutionEngine::createJIT (or EngineBuilder::create) more<br>
>> > than<br>
>> > one time, the second time fails on a assertion "Multiple JIT<br>
>> > resolvers?".<br>
>> > It seems that the JIT is designed to be a singleton in the process, and<br>
>> > I<br>
>> > was wondering if it was something mandatory.<br>
>> > How hard will it be to make it a non-singleton object ? Is this a<br>
>> > JIT-only<br>
>> > problem (work needed on JIT classes only) ? Is it a much wider design<br>
>> > constraint (on codegen ?) ?<br>
>> ><br>
>> > In case, if you ask why I want to create more than one JIT, here is a<br>
>> > reason<br>
>> > :<br>
>> > I have a JIT application which works fine, a thread is responsible to<br>
>> > prepare code execution (work on module, add functions, optimize, call<br>
>> > JIT...) and a another thread is responsible for executing the code<br>
>> > produced<br>
>> > in the first thread.<br>
>> > It works great, but the preparation thread is heavily loaded. I decide<br>
>> > to<br>
>> > look at what happens, if I spawns 2 threads for preparation of the code.<br>
>> > I have a working prototype, which have one module and one context by<br>
>> > thread,<br>
>> > and it works. But the JIT is still shared between 2 threads and the time<br>
>> > needed to emit a function is not negligible. It will be a great boost of<br>
>> > performances, if I can create one execution engine by thread.<br>
>> ><br>
>> > What do you think ? Do you have any comments on it ?<br>
>> > Thanks for reading !<br>
>> ><br>
>> > Olivier.<br>
>> ><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br>