[PATCH] D32061: [wip] Bitcode: Write the irsymtab to disk.

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added inline comments.


================
Comment at: llvm/include/llvm/Object/IRSymtab.h:122
+  /// in symbol table format, symbol enumeration order and so on.
+  Str Producer;
+
----------------
tejohnson wrote:
> pcc wrote:
> > tejohnson wrote:
> > > Does this mean that the symbol table will be thrown away every time the llvm revision changes? Can we avoid that by having a symbol table version number?
> > That would be tricky to get right. There are many things that could change the symbol table, even without changing the format.
> > 
> > For example, a change such as D31443 would re-order the symbol table, despite not touching the bitcode reader at all.
> > 
> > As another example, suppose that we decide to remove an intrinsic from LLVM, and we upgrade existing IR by removing the intrinsic declaration (and changing calls to do something else). That by itself would change the symbol table.
> > 
> > So I think the safest option would be to accept only symbol tables from the same revision of LLVM.
> > For example, a change such as D31443 would re-order the symbol table, despite not touching the bitcode reader at all.
> 
> I guess this makes a different for regularLTO where we need to correlate the symbol resolutions built from the symbol table with the symbols in the module. Presumably it shouldn't matter for something like ThinLTO though, where in the thin link we eventually shouldn't have to look at the module ir at all. Not that this helps much since we don't know the use case. Unfortunate, but I can't think of a way to avoid it offhand, without adding some other way to correlate the module symbols to the symbol table symbols.
>So I think the safest option would be to accept only symbol tables from the same revision of LLVM.

But that's a design decision. The symbol table could be stored as bitcode with the same exact restriction as all the usual compatibility, and avoid any duplication with the rest of the module (i.e. not being able to regenerate the symbol table from the rest of the bitcode is *not* a bad thing to me, quite the opposite).
I'm not sure what makes a symbol table "special" here.



https://reviews.llvm.org/D32061