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

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added inline comments.


================
Comment at: llvm/include/llvm/Object/ModuleSymbolTable.h:42
+  ArrayRef<Symbol> symbols() const { return SymTab; }
+  void addModule(Module *M);
+
----------------
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.



https://reviews.llvm.org/D27073