This is an archive of the discontinued LLVM Phabricator instance.

[lto] Don't lazy load metadata for now.
ClosedPublic

Authored by silvas on Mar 8 2016, 9:24 PM.

Details

Summary

At the very least we hit

Assertion failed: (((Flags & RF_HaveUnmaterializedMetadata) || Node->isResolved()) && "Unexpected unresolved node"), function MapMetadataImpl, file /Users/Sean/pg/llvm/lib/Transforms/Utils/ValueMapper.cpp, line 375.

on the included test case.

We currently do things like parse the module twice to keep the
implementation minimal. I think it makes sense to add start with eager
loading for similar reasons.

Diff Detail

Event Timeline

silvas updated this revision to Diff 50105.Mar 8 2016, 9:24 PM
silvas retitled this revision from to [lto] Don't lazy load metadata for now..
silvas updated this object.
silvas added a reviewer: rafael.
silvas added subscribers: llvm-commits, Bigcheese, ruiu.

With lazy metadata loading something needs to call materializeMetadata before the IRMover is invoked. Not sure there is an advantage to delaying it in this case, but see the suggestion below for where that could be done.

Rafael, should the IRLinker just always invoke materializeMetadata on the module (if shouldLinkMetadata() is true, which will avoid doing that if we plan to do post-pass metadata linking for ThinLTO)? I'm already invoking materializeMetadata when we detect we are in the postpass md linking. Probably could just move that outside the IsMetadataLinkingPostpass guard in IRMover.cpp. I can send a patch right now to do that, I don't know how to test lld but Sean can give it a try.

ELF/SymbolTable.cpp
147

Call M->materializeMetadata() above here as an alternative.

With lazy metadata loading something needs to call materializeMetadata before the IRMover is invoked. Not sure there is an advantage to delaying it in this case, but see the suggestion below for where that could be done.

Rafael, should the IRLinker just always invoke materializeMetadata on the module (if shouldLinkMetadata() is true, which will avoid doing that if we plan to do post-pass metadata linking for ThinLTO)? I'm already invoking materializeMetadata when we detect we are in the postpass md linking. Probably could just move that outside the IsMetadataLinkingPostpass guard in IRMover.cpp. I can send a patch right now to do that, I don't know how to test lld but Sean can give it a try.

See D17992

rafael edited edge metadata.Mar 9 2016, 10:03 AM
rafael added a subscriber: rafael.

Parsing twice is actually a time versus memory tradeoff.

This patch LGTM.

At some point we have to figure out a way of lazy loading metadata and not
copying metadata that is not used, but that is not now.

Cheers,
Rafael

For now we should just not be lazy. A very big future task is making lazy
loading work so that we don't even read metadata we don't need.

Cheers,
Rafael

I work on a patch that does that. But because of the way the bitcode format (and the reader) work, it is terribly intrusive.
I ended embedding all metadata in a "flat buffer" container as a pre-requisite for prototyping, and I got good results out of it.
Long term plan is really to move to a new bitcode format IMO.

This revision was automatically updated to reflect the committed changes.