search for: frontend_generate_symbol

...he LLVM infrastructure currently has something like this: 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_resol...

...gt; 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....

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

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