[PATCH] D31921: Object: Factor out the code for creating the irsymtab for an arbitrary bitcode file.

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 11 20:07:33 PDT 2017


tejohnson added a comment.

In https://reviews.llvm.org/D31921#724280, @pcc wrote:

> In https://reviews.llvm.org/D31921#724251, @tejohnson wrote:
>
> > In https://reviews.llvm.org/D31921#724231, @pcc wrote:
> >
> > > The irsymtab interface lives at a lower layer than IRObjectFile, as the irsymtab interface is specifically designed for IR symbol tables as opposed to the generic object file interface exposed by ObjectFile. I see this function as the layer between the raw irsymtab reader interface and clients such as IRObjectFile (and LTO, etc). So it doesn't seem appropriate for this function to live alongside one specific client, and it doesn't really deserve its own file/namespace, so it might as well live alongside irsymtab.
> >
> >
> > What I don't like is that this is not just parsing the irsymtab structures, but also the modules themselves.
>
>
> True, but that is only an implementation detail. When we start writing the irsymtab to disk, the modules will only be parsed on the "upgrade" code path.


Ok, I forgot about that. Looking now at the InputFile class, the comments indicate it only holds what is necessary for symbol resolution, so I guess the idea is that the Mods field will go away (except I guess on the upgrade path) when we have a real IR symbol table on disk? But then currently the Mods field is used when we add the module for regular LTO, where we do need the full module.


https://reviews.llvm.org/D31921





More information about the llvm-commits mailing list