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
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.