[LLVMdev] 2nd attempt for a working patch for bug 2606

[Olivier Meurant]

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 differents modules, we can create 2 JITs. If one module
needs another module, we can create a LazyFunctionCreator (called by
JIT::getPointerToNamedFunction) and easily resolved cross-module references.

What do you think ? Anyone have an opinion on this ?

Olivier.

On Fri, Feb 19, 2010 at 5:21 PM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote:

> This is the second version of a patch, which I recently attached to bug
> 2606 <http://llvm.org/bugs/show_bug.cgi?id=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 "external" GlobalVariable.
> 2) To solve the foreign Module Function problem,
> I modified JIT.{h,cpp} to emit a stub for a found "external" Function
> instance, when that foreign Module
> defined Function has not yet been compiled.
>
> All areas of interest are marked with // GMV Mod:
>
> Again I invite those members of the list that have time, to review this
> proposal for comments/changes.
>
> Major mods:
>
> JIT.{h,cpp}:
>
> 1) I included Module.h.
>
> 2) JIT::getPointerToFunction(...) was modified to search for a non-mapped
> function in all "other" modules.
> If found a stub is emitted in the same manner as other in module functions
> found. This stub gets re-emitted,
> toward the end of the JIT cycle.
>
> One issue here is that functions that are external to all modules, have
> their mappings delayed by the
> above loop. I also kept the hasAvailableExternallyLinkage() the same as
> before, as I'm not sure if this
> should also go through the same module procedure. The stub emission will
> only take place for function
> definitions that are marked with external linkage. Should other cases be
> allowed? Should visibility also
> be considered?
>
> 3) JIT::getOrEmitGlobalVariable(...) was modified to search for non-mapped
> global variables in all "other"
> modules. If found, the address of the foreign global variable is requested,
> and mapped. There is no
> delay here.
>
> An attempt is first made to find the global outside of all modules, before
> attempting 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 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 simpler for cross module behavior, but current manual
> solutions may be more fined grained in their approach in
> deciding how to treat such functions. If true a fix to 2606<http://llvm.org/bugs/show_bug.cgi?id=2606> would
> circumvent such handling. Should we instead add a new
> semantic to EngineBuilder which would configure the JIT, or whatever else,
> to handle such cross module linkage, if such behavior
> is warranted? By linkage I mean mapping variables, and functions found in
> "external" modules, into the execution engine. For example,
> one could devise a new function pass style metaphor which would be setup in
> the EngineBuilder instance. If it exists, the resulting
> JIT instance would use this new pass style to determine what to do with
> "foreign functions, and variables". However the first question
> is, whether or not 2606 <http://llvm.org/bugs/show_bug.cgi?id=2606> is a
> bug in the first place?
>
> Thanks again for any time spent on this
>
> Garrison
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100225/144acec0/attachment.html>