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

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

In https://reviews.llvm.org/D31921#725253, @tejohnson wrote:

> In https://reviews.llvm.org/D31921#725225, @pcc wrote:
>
> > In https://reviews.llvm.org/D31921#725214, @tejohnson wrote:
> >
> > > Ok, but then I am confused about your earlier response that eventually the modules will only be parsed on the "upgrade" code path? If this outlined function will continue to parse all top level entities in the bitcode file, then I am not sure it belongs in irsymtab.
> >
> >
> > I see the symbol table becoming the top-level entity in the bitcode file in the long term (if we switch to a new bitcode format). But I may be wrong, and I suppose that from that perspective it doesn't matter where the code lives, because it will all be rewritten anyway. So I'm fine with moving it to IRObjectFile if you still think it sohuld go there.
>
>
> To me conceptually the module also a top level entity, but I guess it depends on how you look at it. I'd prefer it in IRObjectFile over having it within irsymtab.


I also realised that moving the code to IRObjectFile means that IRObjectFile and irsymtab will need to conspire to use the same producer string to decide whether to upgrade, whereas without the move the logic is isolated to irsymtab. So I am slightly more against the move now. I will upload my change to start writing the irsymtab files to disk, so you can see what I mean.


https://reviews.llvm.org/D31921