This is an archive of the discontinued LLVM Phabricator instance.

Object: Teach irsymtab::read() to try to use the irsymtab that we wrote to disk.
ClosedPublic

Authored by pcc on Jun 6 2017, 6:00 PM.

Event Timeline

pcc created this revision.Jun 6 2017, 6:00 PM
tejohnson added inline comments.Jun 26 2017, 8:01 PM
llvm/include/llvm/Bitcode/BitcodeReader.h
114

Why not just "Strtab"?

llvm/lib/Bitcode/Reader/BitcodeReader.cpp
5468

Should this assert if we have a string table but StrtabForSymtab is already set, rather than silently skip it?

5479

Similarly, should this assert that the Symtab is empty? Otherwise we are just silently ignoring this symtab, which seems wrong.

llvm/test/Object/X86/irsymtab.ll
8

If the dumper also emitted the producer, you could check that the producer string is as expected for the two cases.

pcc added inline comments.Jun 26 2017, 8:35 PM
llvm/include/llvm/Bitcode/BitcodeReader.h
114

Because a bitcode file may contain multiple string tables if it was created by binary concatenation. The name reflects that it is the string table for the symbol table, not some other string table.

llvm/lib/Bitcode/Reader/BitcodeReader.cpp
5468

If the bitcode file was created by binary concatenation, there may be more than one string table after the symbol table.

5479

Again, that would assert with binary concatenation.

It's fine to silently ignore the symbol table here in that case because this is a low-level function. Later (in IRSymtab.cpp:342) we will realise that the symbol table that we chose has the wrong number of modules, so we will regenerate it.

llvm/test/Object/X86/irsymtab.ll
8

Yeah. I'll see if I can extend the dumper here.

tejohnson added inline comments.Jun 27 2017, 8:44 AM
llvm/include/llvm/Bitcode/BitcodeReader.h
114

Ok

llvm/lib/Bitcode/Reader/BitcodeReader.cpp
5468

Ok, can you just note that in the comment?

5479

Ditto about noting in a comment.

pcc updated this revision to Diff 104299.Jun 27 2017, 3:53 PM
pcc marked 2 inline comments as done.
  • Address review comments
pcc marked an inline comment as done.Jun 27 2017, 3:53 PM
tejohnson added inline comments.Jun 27 2017, 4:21 PM
llvm/test/Object/X86/irsymtab.ll
8

Wouldn't the producer string in this second case be "consumer" since it would have been upgraded?

pcc added inline comments.Jun 27 2017, 4:27 PM
llvm/test/Object/X86/irsymtab.ll
8

The idea is that llvm-lto2 prints the producer string from before the upgrade. That seems more useful than printing the producer from after an upgrade since that's basically equivalent to "print the current producer string".

tejohnson accepted this revision.Jun 27 2017, 4:30 PM

LGTM

llvm/test/Object/X86/irsymtab.ll
8

Ok true

This revision is now accepted and ready to land.Jun 27 2017, 4:30 PM
This revision was automatically updated to reflect the committed changes.