This is an archive of the discontinued LLVM Phabricator instance.

Bitcode: Make the summary reader responsible for merging. NFCI.
ClosedPublic

Authored by pcc on Apr 24 2017, 9:50 PM.

Details

Summary

This is to prepare for an upcoming change which uses pointers instead of
GUIDs to represent references.

Depends on D32195

Diff Detail

Repository
rL LLVM

Event Timeline

pcc created this revision.Apr 24 2017, 9:50 PM
tejohnson added inline comments.Apr 28 2017, 9:19 AM
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
4682 ↗(On Diff #96498)

Can we instead add the module path in the constructor, then I think there is no need to save the ModuleId in the class? And then this can be changed to something like getThisModulePath and have it return the StringRef. In the one place where this was being called to get the Hash reference, you could then instead invoke the existing getModuleHash().

4997 ↗(On Diff #96498)

Actually, I believe the need for this went away with D19462, which reorganized the data structures and the way that we built the index during summary parsing so that we no longer created the summary entries eagerly during VST parsing. In fact, the stated need for it here is even more true with this patch (that we merge everything into the first module), so this patch wouldn't have removed the need for this if we hadn't already removed it. Can you commit the change to remove this separately?

5503 ↗(On Diff #96498)

Spurious new line added here? No other change to the original line.

llvm/lib/LTO/ThinLTOCodeGenerator.cpp
573 ↗(On Diff #96498)

Previously the first module's index would get module ID 0 (since we simply used the first parsed module index as the combined index). But I don't think this has any meaningful impact, right? Anyway, it is more consistent with llvm-lto which will also start the numbering at 1.

pcc marked an inline comment as done.Apr 28 2017, 11:10 AM
pcc added inline comments.
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
4682 ↗(On Diff #96498)

The problem is that we don't know until we start parsing the file whether it is a per-module summary or a combined summary, so we could end up adding an entry for the combined summary file in the list of module paths. I guess we could avoid this problem by changing the API so that getSummary is only used for combined summaries and readSummary for per-module summaries, but that can probably be done separately.

4997 ↗(On Diff #96498)

r301660.

llvm/lib/LTO/ThinLTOCodeGenerator.cpp
573 ↗(On Diff #96498)

I don't think it matters, but it could change the contents of the combined summary bitcode file and this change is supposed to be NFC, so I've changed it back.

pcc updated this revision to Diff 97127.Apr 28 2017, 11:10 AM
  • Address review comments
tejohnson accepted this revision.Apr 28 2017, 11:32 AM

LGTM, with minor comment nits below.

llvm/lib/Bitcode/Reader/BitcodeReader.cpp
710 ↗(On Diff #97127)

Document

5487 ↗(On Diff #97127)

This comment goes with getSummary().

4682 ↗(On Diff #96498)

I see, ok nevermind for now then.

This revision is now accepted and ready to land.Apr 28 2017, 11:32 AM
This revision was automatically updated to reflect the committed changes.
pcc marked 2 inline comments as done.