[LLVMdev] Hooking the global symbol resolver

[Óscar Fuentes]

"Jonathan S. Shapiro" <shap at eros-os.com> writes:

[snip]

>   if (!(sym = llvm_resolve_global(GlobalScope, symName)))
>     some_failure_action();
>
> it would now look something like:
>
>   sym = llvm_resolve_global(GlobalScope, symName);
>   if (!sym && frontend_has_symbol_generator
>       && frontend_generate_symbol(symname))
>     // Note: if frontend_generate_symbol() has succeeded, it will have
>     // constructed some LLVM Module and called the LLVM compiler to
>     // admit it, with the consequence that GlobalScope will have been
>     // updated to contain a binding for the desired symbol.
>     sym = llvm_resolve_global(GlobalScope, symName);
>   if (!sym)
>     some_failure_action();
>
> I don't think that it's any more complicated than that. This is
> basically the test that our static polyinstantiator runs right now.
>
> Note: I'm still not claiming that this is a good approach in the context
> of LLVM. I don't have my head wrapped around LLVM enough to have an
> opinion about that. I simply wanted to make sure that the question was
> clearly framed.
>
> I do, provisionally, think that this particular hook is consistent with
> the notion of continuous compilation. It seems (to me) necessary (and
> perhaps even sufficient) to let the front end participate in the
> continuousness of continuous compilation.

I'm all for hooks and delegation, but the problem here is that your
proposal is not general enough and is hard to generalize it. It does not
work for my project, for instance, although I face almost the same
requirements than you wrt dynamic generation. The symbol name is enough
for you, but not for me, and there is no way to teach LLVM about what
info I need.

This doesn't mean that the LLVM developers shouldn't consider your
proposal on the context of the typical LLVM user. Maybe your case is
common enough.

-- 
Oscar