This is an archive of the discontinued LLVM Phabricator instance.

Object: Have the irsymtab builder take a string table builder. NFCI.
ClosedPublic

Authored by pcc on Jun 6 2017, 5:57 PM.

Details

Summary

This will be needed in order to share the irsymtab string table with
the bitcode string table.

Depends on D33969

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Jun 6 2017, 5:57 PM
tejohnson added inline comments.Jun 20 2017, 9:35 PM
llvm/lib/Object/IRSymtab.cpp
52 ↗(On Diff #101651)

Why pass in the BumpPtrAllocator as well? I don't see that being shared in this or any follow-on patches?

55 ↗(On Diff #101651)

Move this data member up above constructor that now sets it, adjacent to the other members initialized by the constructor.

241 ↗(On Diff #101651)

Why this change? We had a StringSaver before, and weren't using it here.

pcc added inline comments.Jun 20 2017, 9:54 PM
llvm/lib/Object/IRSymtab.cpp
52 ↗(On Diff #101651)

The BumpPtrAllocator owns any strings that are created by this code. This is necessary because the StringTableBuilder does not take ownership of any strings that are added to it. This change makes it possible for the lifetime of the strings to extend past the lifetime of the Builder.

55 ↗(On Diff #101651)

Will do

241 ↗(On Diff #101651)

Previously the lifetime of StrtabBuilder was effectively [1] shorter than that of the COFFLinkerOpts string, so StrtabBuilder was able to share ownership of the string with COFFLinkerOpts. Now that StrtabBuilder outlives the string, we need to save it in the StringSaver.

[1] "Effectively" meaning that we were done with StrtabBuilder before returning from build(). Of course StrtabBuilder's actual lifetime was longer because it is a field. I guess we were just getting lucky that its destructor presumably didn't need to access the string.

tejohnson accepted this revision.Jun 21 2017, 7:25 AM

LGTM with the suggested comment and move of the StringSaver declaration.

llvm/lib/Object/IRSymtab.cpp
52 ↗(On Diff #101651)

Ok, can you document this on the constructor? It would probably be clearer to have a single data structure that owns all these things that need the same lifetime (the StringTableBuilder, BumpPtrAllocator and possibly the StringSaver for simplicity), but that can be considered for a follow on refactoring.

This revision is now accepted and ready to land.Jun 21 2017, 7:25 AM
This revision was automatically updated to reflect the committed changes.
pcc marked an inline comment as done.