[PATCH] D27073: Object: Extract a ModuleSymbolTable class from IRObjectFile.

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added inline comments.


================
Comment at: llvm/include/llvm/Object/ModuleSymbolTable.h:42
+  ArrayRef<Symbol> symbols() const { return SymTab; }
+  void addModule(Module *M);
+
----------------
pcc wrote:
> mehdi_amini wrote:
> > Could it take a `MemoryBufferRef` and construct a lazy module that it would own? The fact that a Module is created should be an implementation detail.
> > 
> > That seems closer to the goal of having a symbol table in the bitcode file, and will help designing the client APIs appropriately.
> > 
> So the idea here is that this class would be the low-level interface to be used in the case where you know you're dealing with an actual IR module in memory. That's why the class exposes GlobalValues for example.
> 
> When symbol tables are introduced, there would be a separate class that would be the low-level interface to the bitcode symbol table. That class would be used by IRObjectFile and lto::InputFile. lib/LTO would also continue to use ModuleSymbolTable in places like LTO::addRegularLTO where it deals with a loaded module.
> 
> I'm sorry if I didn't make this clear enough in the discussion on D26951.
> 
If this is the low-level interface, what is the high-level one that abstracts away the difference between the low-level ones?
I wouldn't expect the low-level ones to be used in IRObjectFile or lib/LTO, why is that?



https://reviews.llvm.org/D27073