This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] Import composite types as declarations
ClosedPublic

Authored by tejohnson on Dec 14 2016, 2:02 PM.

Details

Summary

When reading the metadata bitcode, create a type declaration when
possible for composite types when we are importing. Doing this in
the bitcode reader saves memory. Also it works naturally in the case
when the type ODR map contains a definition for the same composite type
because it was used in the importing module (buildODRType will
automatically use the existing definition and not create a type
declaration).

For Chromium built with -g2, this reduces the aggregate size of the
generated native object files by 66% (from 31G to 10G). It reduced
the time through the ThinLTO link and backend phases by about 20% on
my machine.

Diff Detail

Repository
rL LLVM

Event Timeline

tejohnson updated this revision to Diff 81463.Dec 14 2016, 2:02 PM
tejohnson retitled this revision from to [ThinLTO] Import composite types as declarations.
tejohnson updated this object.
tejohnson added a subscriber: llvm-commits.
aprantl edited edge metadata.Dec 14 2016, 2:58 PM

This sounds like it could break debugging with LLDB. If I understand the description correctly, this is the equivalent of doing -fno-standalone-debug?

mehdi_amini edited edge metadata.Dec 14 2016, 4:52 PM

The patch does not seem to apply cleanly?

tejohnson updated this revision to Diff 81513.Dec 14 2016, 6:05 PM
tejohnson edited edge metadata.

Rebase

The patch does not seem to apply cleanly?

Should be fixed by my rebase - there was a merge conflict in LTOBackend.cpp when I tried updating initially.

Mehdi and I just ran a couple of experiments. LLDB can find forward-declared composite types that are defined in another .o file just fine; the only caveat is that LLDB has to potentially load the accelerator table of each .o file from disk in order to find the .o file with the definition in it. Judging from this, I think that this approach is fine.

Mehdi and I just ran a couple of experiments. LLDB can find forward-declared composite types that are defined in another .o file just fine; the only caveat is that LLDB has to potentially load the accelerator table of each .o file from disk in order to find the .o file with the definition in it. Judging from this, I think that this approach is fine.

Does the patch look ok to commit?

mehdi_amini added inline comments.Dec 16 2016, 9:41 AM
lib/Bitcode/Reader/MetadataLoader.cpp
733 โ†—(On Diff #81513)

Can you avoid calling all the getMD and so above in the case you're nullifying them?
As I'm working on lazy-loading, this would still trigger the load from bitcode and create the MD into memory even if you don't attach them in the MD graph.

mehdi_amini accepted this revision.Dec 16 2016, 9:41 AM
mehdi_amini edited edge metadata.

Otherwise, LGTM.

This revision is now accepted and ready to land.Dec 16 2016, 9:41 AM

Yes this is fine.

tejohnson added inline comments.Dec 16 2016, 1:30 PM
lib/Bitcode/Reader/MetadataLoader.cpp
733 โ†—(On Diff #81513)

Good idea, done.

tejohnson updated this revision to Diff 81789.Dec 16 2016, 1:34 PM
tejohnson edited edge metadata.
  • Avoid getMD calls if we aren't going to use the created metadata
  • Add llvm-lto2 based test
  • Rebase
This revision was automatically updated to reflect the committed changes.
aprantl added inline comments.Jan 3 2017, 9:14 AM
llvm/trunk/lib/Bitcode/Reader/MetadataLoader.cpp
750

Sorry for bringing this up so late, but I just realized that this is only legal if the Identifier field is nonempty. The ODR (or an equivalent rule in the underlying source language) only applies to types with an identifier field. In C, for example, it is legal for multiple translation units to contain definitions of types with the same name, but a different layout. Using just the name it is impossible for the debugger to find the correct definition of a forward-declared type in the other translation units.

tejohnson added inline comments.Jan 3 2017, 11:41 AM
llvm/trunk/lib/Bitcode/Reader/MetadataLoader.cpp
750

Ok, I can make the decl optimization conditional on the Identifier being non-null. I assume that is not the common case anyway - in which case that change shouldn't hurt the overall impact much?

tejohnson added inline comments.Jan 3 2017, 3:31 PM
llvm/trunk/lib/Bitcode/Reader/MetadataLoader.cpp
750

r290915

On Chromium, the fix increases the aggregate -g2 object file sizes with ThinLTO by almost 4%, but it just means a 65% reduction over the object files before this patch, instead of the original 66% reduction.