This is an archive of the discontinued LLVM Phabricator instance.

[ThinLTO] Enable importing of aliases as copy of aliasee
ClosedPublic

Authored by tejohnson on Dec 1 2017, 1:03 PM.

Details

Summary

This implements a missing feature to allow importing of aliases, which
was previously disabled because alias cannot be available_externally.
We instead import an alias as a copy of its aliasee.

Some additional work was required in the IndexBitcodeWriter for the
distributed build case, to ensure that the aliasee has a value id
in the distributed index file (i.e. even when it is not being
imported directly).

This is a performance win in codes that have many aliases, e.g. C++
applications that have many constructor and destructor aliases.

Event Timeline

tejohnson created this revision.Dec 1 2017, 1:03 PM

Just a quick note:

Could you check what the debug info looks like for an imported alias that is inlined, and one that isn't inlined?

Specifically my concern is over whether or not this causes a second CU to be created - currentyl we're threading a needle to avoid fixing/updating GDB by not needing multiple CUs per DWO file due to importing cross-CU inlining into the calling CU, etc.

Can talk more offline or through this thread.

Just a quick note:

Could you check what the debug info looks like for an imported alias that is inlined, and one that isn't inlined?

Specifically my concern is over whether or not this causes a second CU to be created - currentyl we're threading a needle to avoid fixing/updating GDB by not needing multiple CUs per DWO file due to importing cross-CU inlining into the calling CU, etc.

Can talk more offline or through this thread.

On-list update: David and I discussing offline. But essentially the same thing happens to debug info when we import an alias vs a normal function. David is looking at whether that is correct, but we are consistent. This is expected since the imported aliases (copies of aliasee) are available_externally just like other imported functions.

pcc edited edge metadata.Dec 6 2017, 1:22 PM

Now that we basically treat alias summaries in the same way as their aliasees, I wonder whether we can simplify things by removing AliasSummary and summarizing aliases by creating a FunctionSummary or GlobalVariableSummary from the aliasee instead.

In D40747#947144, @pcc wrote:

Now that we basically treat alias summaries in the same way as their aliasees, I wonder whether we can simplify things by removing AliasSummary and summarizing aliases by creating a FunctionSummary or GlobalVariableSummary from the aliasee instead.

I'm not sure we can as there are other requirements for knowing the alias relationship. For example, we can't convert a non-prevailing alias and aliasee to available_externally (see thinLTOResolveWeakForLinkerGUID) - that is in the original module and not related to importing.

ping - Peter, would you be able to take a look at the changes?

pcc added a comment.Dec 15 2017, 10:52 AM
In D40747#947144, @pcc wrote:

Now that we basically treat alias summaries in the same way as their aliasees, I wonder whether we can simplify things by removing AliasSummary and summarizing aliases by creating a FunctionSummary or GlobalVariableSummary from the aliasee instead.

I'm not sure we can as there are other requirements for knowing the alias relationship. For example, we can't convert a non-prevailing alias and aliasee to available_externally (see thinLTOResolveWeakForLinkerGUID) - that is in the original module and not related to importing.

That could be resolved by adding a HasAlias flag to GlobalValueSummary, no? We would set it on aliases and anything that is aliased.

Sorry for the delay, I was working on prototyping my suggested change to make sure that it would work (and so far it looks like it would). This is probably fine for now though.

lib/Transforms/IPO/FunctionImport.cpp
127

I see why this is needed for now, but it seems like there is a possibility that we could make the distributed combined summary format simpler by not including a summary at all but just the names of the globals that need to be imported.

test/ThinLTO/X86/funcimport.ll
21

I think you want to remove this line.

test/Transforms/FunctionImport/funcimport.ll
39

imported (same below)

tejohnson marked 2 inline comments as done.Dec 15 2017, 12:00 PM
In D40747#956983, @pcc wrote:
In D40747#947144, @pcc wrote:

Now that we basically treat alias summaries in the same way as their aliasees, I wonder whether we can simplify things by removing AliasSummary and summarizing aliases by creating a FunctionSummary or GlobalVariableSummary from the aliasee instead.

I'm not sure we can as there are other requirements for knowing the alias relationship. For example, we can't convert a non-prevailing alias and aliasee to available_externally (see thinLTOResolveWeakForLinkerGUID) - that is in the original module and not related to importing.

That could be resolved by adding a HasAlias flag to GlobalValueSummary, no? We would set it on aliases and anything that is aliased.

Possible yes.

Sorry for the delay, I was working on prototyping my suggested change to make sure that it would work (and so far it looks like it would). This is probably fine for now though.

Ok thanks. Let's consider that for a follow on change?

lib/Transforms/IPO/FunctionImport.cpp
127

I took a quick look and it appears that there is one place we use other info out of the summaries for imported values: setting DSOLocal in FunctionImportGlobalProcessing::processGlobalForThinLTO. It's possible that we may add other flags that we want to propagate in the summary to be set on imported values too, so I'm not very enthusiastic on removing those summaries altogether.

Address comments

pcc accepted this revision.Dec 15 2017, 1:20 PM

LGTM

lib/Transforms/IPO/FunctionImport.cpp
127

It's possible that we could split what is currently the GlobalValueSummary into a summary part and a "resolution" part (the resolutions would be stored in a separate index), and then just store the resolutions in what is currently the summary file. This could not only make the flow of information more understandable, but it would allow us to break the 1:1 correspondence between summaries and resolutions, which is problematic for DSO local right now because it can apply to declarations as well as definitions (so right now we can end up dropping the DSO local bit on declarations that don't have summaries).

This revision is now accepted and ready to land.Dec 15 2017, 1:20 PM
This revision was automatically updated to reflect the committed changes.