[PATCH] D75087: [ORC] Add LookupKind::TransitiveStatic for linker-resolved transitive dependencies

[Stefan Gränitz via Phabricator via llvm-commits]

sgraenitz marked an inline comment as done.
sgraenitz added a comment.

In D75087#1904552 <https://reviews.llvm.org/D75087#1904552>, @lhames wrote:

> So the aim here is to enable generation of lazy stubs without having to materialize any IR, right?


Right, AND without having to parse the respective bitcode files. In many cases the main module has transitive dependencies to a huge number of modules and materializing it causes parsing and emitting reexports for all of them. I do see that the case, which I refer to as `TransitiveStatic` here, could be the default for my generator. Entry points would then get a synthetic call-through too and load&emit the module on call (that would be acceptable). The problem, however, would then be the lookups issued from discovery. These should cause materialization of the requested modules. Unfortunately, there isn't a good way for the generator to distinguish them either (see inline comment).

> I think the right way to do this: They’re supposed to have just enough information to decide whether the materialization unit being added should be part of the JIT’d program or not. They’re not intended for making smart decisions about how to build the materialization units.
> 
> I think a better approach would be to define a ModuleSummaryMaterializationUnit (or something similar) and have that be the thing that you add to your JIT layer. The layer would build stubs based on the interface defined in the module summary and defer compilation of the IR.

Not sure if that goes too much into the details, but one issue here is that module summaries only provide GUIDs. I don't have the full interface before parsing bitcode. The only symbol names I know are the requested ones.

The underlying question for me was, whether -- in general -- it could make sense for generators to distinguish between lookups coming from the linker and lookups from the "user".



================
Comment at: llvm/examples/ThinLtoJIT/ThinLtoJIT.cpp:263
   auto SymMap = ES.lookup(SearchOrder, LookaheadSymbols,
                           LookupKind::Static, SymbolState::Ready);
 
----------------
This is the lookup issued from discovery. It's intended to force materialization of the modules that define `LookaheadSymbols`. As described above, I could assume `TransitiveStatic` the default. Then I'd probably pass `LookupKind::DLSym` here for the generator to indicate forced materialization, but that would be an abuse too.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75087/new/

https://reviews.llvm.org/D75087