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

Jeffrey Yasskin jyasskin at google.com
Thu Feb 25 13:48:14 PST 2010

On Thu, Feb 25, 2010 at 11:10 AM, Olivier Meurant
<meurant.olivier at gmail.com> 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 ?
> 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.

The LazyFunctionCreator has to guarantee that it returns non-null for
existing functions or the JIT will abort. If you have recursion across
modules, and the LazyFunctionCreator tries to compile them, that'll
either fail or try to compile recursively, which also fails an
assertion. So I think the single JIT dealing with multiple modules
will work better.

> 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, 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 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 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 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list