[LLVMdev] Hooking the global symbol resolver

[Gordon Henriksen]

Hi Jonathan,

In the context of a static compiler, I would recommend that you  
implement your own “on the side” symbol table in order to track this  
state and perform on-demand instantiation as required. It is  
worthwhile to consider the LLVM module to be a passive output sink,  
not an active object.

The JIT compiler, by contrast, is an active object, cooperating with  
its environment via the ModuleProvider interface. Overriding  
materializeFunction should be useful for on-demand instantiation.

— Gordon

On Mar 26, 2008, at 17:07, Jonathan S. Shapiro wrote:

> Okay, we're starting to dig in, and I've hit a question that will no  
> doubt seem strange.
>
> Context: BitC is a polymorphic language. Since it has unboxed value  
> types, our approach to compiling a polymorphic function is to  
> polyinstantate it -- once for each signature.
>
> The name mangling scheme is both stable and reversible. At the site  
> of the use occurrence, we can fully determine the mangled name of  
> the desired instantiation. Given the mangled name of an  
> instantiation that has not yet been synthesized, we can determine  
> which procedure must be synthesized.
>
> At present, our front end implements a demand-driven instantiator  
> that proceeds from main() until all calls are statically resolved.
>
> It seems to me, however, that this duplicates (nearly) functionality  
> that is probably already present in the LLVM JIT layer.
>
> Here is what I am wondering:
>
> Is there some way we can "hook" the global symbol resolver so that  
> we can run the polyinstantiator on demand? I *think* this could be  
> done by running the resolver normally, noticing failure on a symbol  
> that we know ought to exist, code generating the instance definition  
> corresponding to the needed symbol, and then re-performing the  
> lookup at global scope.
>
> What I'm not sure about here is several issues:
>
>  1. Does this make sense?
>
>  2. If so, where is the right place to hook the resolver?
>
>  3. Are we going to run into trouble arising from the fact that we
>     are likely to end up using the module compiler in a recursive
>     way? That is: the referencing module's compile will (in effect) be
>     paused in its symbol resolution phase while we introduce a new
>     module and compile that. I can imagine implementations where this
>     would wreak serious havoc on the implementation of environments
>     within the LLVM infrastructure.
>
>  4. Is there a better/cleaner approach? What other options should I
>     consider?
>
> We can, thankfully, ensure that this recursive instantiation  
> exercise terminates. :-)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080327/6cd566a2/attachment.html>