Page MenuHomePhabricator

Add a new BitcodeSymbolTable abstraction for bitcode files, and migrate IRObjectFile, llvm-nm, and LTO to use it
AbandonedPublic

Authored by mehdi_amini on Aug 3 2016, 12:55 PM.

Details

Summary

This is related to http://lists.llvm.org/pipermail/llvm-dev/2016-May/100190.html
And https://llvm.org/bugs/show_bug.cgi?id=27551

It is a first step toward having an easy and fast to access Symbol
Table in Bitcode Files so that they can be handled as regular
object files by tools like llvm-ar, llvm-nm, or by linkers during
LTO.

The SymbolTable abstraction will provide backward compatiblity for
existing bitcode files, and as soon as it is stable enough, we'll
be able to evolve the format to make it more efficient to build.

The existing approach is IRObjectFile, it is implemented on top
of the IR: it requires a LLVMContext and will parse the Module.
The newly introduced replacement, BitcodeObjectFile, is using the
BitcodeSymbolTable which is built out of the bitcode without
having to generate any IR construct.
It means that on the long term, we should be able to build tools
like llvm-nm that wouldn't needs to link-in the target for instance.

LTOModule/libLTO.dylib as well as llvm-nm have been converted to
use this new class.

Diff Detail

Event Timeline

mehdi_amini retitled this revision from to Add a new BitcodeSymbolTable abstraction for bitcode files, and migrate IRObjectFile, llvm-nm, and LTO to use it.
mehdi_amini updated this object.
mehdi_amini added reviewers: davide, dexonsmith, pcc.
mehdi_amini added a subscriber: llvm-commits.
mehdi_amini updated this revision to Diff 66704.Aug 3 2016, 1:33 PM

Minor fix: Add missing header declaration

pcc edited edge metadata.Sep 14 2016, 4:04 PM

Before reviewing the details of this patch, a higher level point (as discussed on IRC):

You've started with an implementation that takes bitcode and produces a symbol table data structure. I think a better starting point would be to take in-memory IR and produce a symbol table. This has the advantage of being more in line with the desired end state, where the symbol table is required, producers create a bitcode symbol table from in-memory IR, and consumers read the symbol table directly with no upgrade path from existing symbol tables.

pcc added a comment.Sep 14 2016, 4:05 PM

And although this may represent a performance hit, I don't expect it to be significant.

That's a very good point, I'll work on this! Thanks.

include/llvm/Bitcode/ReaderWriter.h
104

Not to myself: alignment is missing

davide edited edge metadata.Dec 13 2016, 7:00 PM

That's a very good point, I'll work on this! Thanks.

Are you still working on this code, or Peter's work makes this obsolete?

mehdi_amini abandoned this revision.Dec 13 2016, 8:36 PM

That's a very good point, I'll work on this! Thanks.

Are you still working on this code, or Peter's work makes this obsolete?

I'm actively working on the long term solution that revisit the bitcode "in depth". This is why I let Peter take the immediate step to provide the symbol table (I'll be careful about the API there since it'll interact with my work when we get there). I left this open as a reference, but we can close it now.