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

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

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

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


Can you clarify how this would make the upgrade decision difficult? I.e. I was envisioning having the main entry point to create and return the new "File" struct in IRObjectFile, which would then invoke irsymtab::read to fill in the Symtab and Strtab. In https://reviews.llvm.org/D32061, it looks like the decision to take the upgrade path based on the producer string only involves those two structures. Why would the IRObjectFile need to know about the producer string?


https://reviews.llvm.org/D31921