This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] Thin link efficiency: Pre-compute set of non-exportable GVs
AbandonedPublic

Authored by tejohnson on Dec 28 2016, 2:19 PM.

Details

Reviewers
mehdi_amini
Summary

Rather than looking up each referenced GUID in the index for each
value we consider importing, in order to see if it is not exportable
(e.g. needs renaming but can't be renamed), pre-compute the set of GUIDs
that can't be exported and consult that.

For a large application with aggressive importing thresholds, the index
lookup findGlobalValueSummaryList in canBeExternallyReferenced was
at the top of the profile. This change reduced the thin link time by
19% on average (the improvement was <1% on average with default
importing thresholds). For my large app, with default thresholds, there
were previously 6.1M index lookups in canBeExternallyReferenced, but with
aggressive importing thresholds there were 195M checks. The index
has 2.8M entries, while the pre-computed DoNotExport set has 13K entries.
There was no significant memory increase from the extra set.

Event Timeline

tejohnson updated this revision to Diff 82620.Dec 28 2016, 2:19 PM
tejohnson retitled this revision from to [ThinLTO] Thin link efficiency: Pre-compute set of non-exportable GVs.
tejohnson updated this object.
tejohnson added a reviewer: mehdi_amini.
tejohnson added a subscriber: llvm-commits.
mehdi_amini added inline comments.Dec 28 2016, 3:04 PM
lib/Transforms/IPO/FunctionImport.cpp
144

What about replacing all of this logic by a bit in the summary that would be set during the compile phase?

tejohnson added inline comments.Dec 29 2016, 7:21 AM
lib/Transforms/IPO/FunctionImport.cpp
144

I like that idea. I started adding a flag this morning that was specific to this case (HasNotExportableReference). But it occurred to me - should we just subsume all checks done by eligibleToImport into a single flag like NotEligibleToImport? That would subsume the new flag as well as the NoRename, IsNotViableToInline and HasInlineAsmMaybeReferencingInternal flags. I.e. anything that today has any of the NoRename, IsNotViableToInline or HasInlineAsmMaybeReferencingInternal set would be marked NotEligibleToImport. Additionally, anything that references something that would today be marked NoRename would also be marked NotEligibleToImport (the case I want to add here).

With any of these new flags we'd need to bump the INDEX_VERSION. However, with the approach of subsuming all of these flags into one we'd need to conservatively always set NotEligibleToImport for old versions, whereas with a new flag we could reproduce it on the fly for older version bitcode out of the other flags (essentially do what the current eligibleToImport() routine does). Not sure how important it is to optimize for this case (handling the older bitcode) though.

WDYT?

mehdi_amini added inline comments.Dec 29 2016, 10:09 AM
lib/Transforms/IPO/FunctionImport.cpp
144

But it occurred to me - should we just subsume all checks done by eligibleToImport into a single flag like NotEligibleToImport?

That's what I had in mind :)

hat would subsume the new flag as well as the NoRename, IsNotViableToInline and HasInlineAsmMaybeReferencingInternal flags. I.e. anything that today has any of the NoRename, IsNotViableToInline or HasInlineAsmMaybeReferencingInternal set would be marked NotEligibleToImport.

I haven't thought about the exact list of flags that this would subsume, but I trust you to eliminate what's not needed!

Not sure how important it is to optimize for this case (handling the older bitcode) though.

Not important IMO. We don't have a widespread adoption of ThinLTO.

tejohnson added inline comments.Dec 29 2016, 10:32 AM
lib/Transforms/IPO/FunctionImport.cpp
144

That's what I had in mind :)

Ok, cool. Wanted to confirm before I started ripping things out too much. =) Will proceed.

tejohnson abandoned this revision.Dec 29 2016, 4:27 PM

Subsumed by D28169.