[LLVMdev] Hooking the global symbol resolver

[Jonathan S. Shapiro]

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. :-)


shap