Page MenuHomePhabricator

[IRMover] Don't map globals if their types are the same
ClosedPublic

Authored by pirama on Aug 27 2019, 11:15 AM.

Details

Summary

During IR Linking, if the types of two globals in destination and source
modules are the same, it can only be because the global in the
destination module is originally from the source module and got added to
the destination module from a shared metadata.

We shouldn't map this type to itself in case the type's components get
remapped to a new type from the destination (for instance, during the
loop over SrcM->getIdentifiedStructTypes() further below in
IRLinker::computeTypeMapping()).

Fixes PR40312.

Diff Detail

Repository
rL LLVM

Event Timeline

pirama created this revision.Aug 27 2019, 11:15 AM
tejohnson added inline comments.Aug 27 2019, 11:52 AM
llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

Can you confirm how the DGV was added to the DstM originally? Do you mean it was already imported from SGV based on information in the summary? We don't directly add from the module summary, it is just used to compute the list of GVs to import from a source here via the IRMover.

pirama updated this revision to Diff 217495.Aug 27 2019, 2:27 PM
pirama marked an inline comment as done.

Fix typo reffers -> refers

llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

Yes, even without this change, DGV was added to DstM.

Here's the path that I traced inside a debugger:

Inputs/type-mapping-bug3.ll: function 'a' has attached debug metadata !6
Parsing that metadata ends up at metadata !5 (which is shared between both input files)
In type-mapping-bug3.ll, processing !5 leads to !7 which is a ConstantAsMetadata, with value as the function declaration.

This value/declaration gets added to DstM in Mapper::mapSimpleMetadata in ValueMapper.cpp.

pirama marked an inline comment as done.Aug 27 2019, 8:40 PM
pirama added inline comments.
llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

Btw, this (GlobalValue from SrcM already added to DstM) happens for PR37684 (test/LTO/X86/type-mapping-bug2.ll) as well. It's just that the types get appropriately mapped if this type and component types don't involve opaque types. This fix is to handle the case where opaque types are involved.

Also, skipping the mapping here is at worst a delayed optimization since they should get resolved appropriately via TypeMapper::get.

tejohnson added inline comments.Aug 29 2019, 2:16 PM
llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

I still don't understand the comment about the module summary, which is just telling the IRMover which symbols to move. What are DGV and SGV in the case where the types match?

llvm/test/LTO/X86/Inputs/type-mapping-bug3.ll
9 ↗(On Diff #217495)

Second sentence is incomplete.

llvm/test/LTO/X86/type-mapping-bug3.ll
41 ↗(On Diff #217495)

Comment seems stale - there is no !11

45 ↗(On Diff #217495)

%t0.o?

pirama updated this revision to Diff 218787.Sep 4 2019, 2:04 PM

Update/clean-up comments in the test.

pirama marked 4 inline comments as done.Sep 4 2019, 2:06 PM
pirama added inline comments.
llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

I incorrectly used "module summary" in the patch. The value is getting loaded via a shared metadata node (!5 in both test inputs)

pirama marked an inline comment as not done.Sep 4 2019, 2:06 PM

Ping...

@tejohnson Did my reply about shared metadata clarify your question?

Ping...

@tejohnson Did my reply about shared metadata clarify your question?

It makes more sense to me (note the summary description of the patch needs to be adjusted similarly, it still refers to the summary). I have a couple more questions below.

llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

In the test SGV and DGV are @d?

llvm/test/LTO/X86/Inputs/type-mapping-bug3.ll
23 ↗(On Diff #218787)

"refers to by" doesn't make sense. Do you mean "refers to !5 in..."?

llvm/test/LTO/X86/type-mapping-bug3.ll
3 ↗(On Diff #218787)

It's a little odd to say that the copy of d from this module is prevailing, since it is just a declaration. Can this be "%t1.o,d," and would that still trigger the error without your fix?

20 ↗(On Diff #218787)

"when its type is mapped to itself incorrectly"?

pirama marked 4 inline comments as done.Sep 11 2019, 11:02 AM

(note the summary description of the patch needs to be adjusted similarly, it still refers to the summary).

Aah, phabricator is not showing my updated commit message. I'll manually update the summary.

llvm/lib/Linker/IRMover.cpp
765 ↗(On Diff #217441)

Yes.

llvm/test/LTO/X86/type-mapping-bug3.ll
3 ↗(On Diff #218787)

Yes, the error is triggered by %t1.o,d,. I've updated the test to %t1.o,d, since that seems the preferred input.

pirama updated this revision to Diff 219744.Sep 11 2019, 11:03 AM
  • Do not have a declaration as a prevailing symbol in llvm-lto2's arguments
  • Fix comments in test
pirama edited the summary of this revision. (Show Details)Sep 11 2019, 11:04 AM
This revision is now accepted and ready to land.Sep 11 2019, 11:09 AM
This revision was automatically updated to reflect the committed changes.