search for: llvm_resolve_global

...y to view Modules as active things. It was not my intention to "extend" a module in mid compile. Rather, it was my thought that we could provide the unresolved symbol by emitting and compiling a second module. Where the 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,...

"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 fro...

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