[PATCH] D26951: Object: Make IRObjectFile own multiple modules and enumerate symbols from all modules.

[Peter Collingbourne via llvm-commits]

pcc added a comment.

In https://reviews.llvm.org/D26951#603447, @mehdi_amini wrote:

> In https://reviews.llvm.org/D26951#603439, @pcc wrote:
>
> > An important point which I forgot to mention: the symbol table stored by ModuleSymbolTable would correspond to any number of modules (all of the same target triple).
>
>
> That seems an arbitrary choice, that is only driven by the current use case of splitting vtables for LTO.


I think in general there are two possible cases:

1. where by design the client needs to have multiple conceptual "views" into the input file (e.g. fat binaries, CUDA, OpenMP)
2. where the client has a single "view" and does not care about which symbol is defined in which module (e.g. regular/thin LTO splitting)

The client's use of ModuleSymbolTable (and the rest of the lib/Object interface in general) needs to be driven by that fundamental design decision of where the split lies. So for the fat binary scenario I would see the client creating one ModuleSymbolTable (and one bitcode symbol table) for each architecture, and the IRObjectFile growing a way to choose the architecture (as we do in MachOObjectFile for example).


https://reviews.llvm.org/D26951