Page MenuHomePhabricator

IRMover: Account for matching types present across modules

Authored by vlad.tsyrklevich on Jun 7 2018, 11:46 AM.



Due to uniqueing of DICompositeTypes, it's possible for a type from one
module to be loaded into another earlier module without being renamed.
Then when the defining module is being IRMoved, the type can be used as
a Mapping destination before being loaded, such that when it's requested
using TypeMapTy::get() it will fail with an assertion that the type is a
source type when it's actually a type in both the source and
destination modules. Correctly handle that case by allowing a non-opaque
non-literal struct type be present in both modules.

Fix for PR37684.

Diff Detail


Event Timeline

vlad.tsyrklevich added a subscriber: tobiasvk.

I tested this change by building Chromium with ThinLTO and self-hosting LLVM/clang with monolithic LTO with module summaries (e.g. with D34156 applied)

  • Limit this logic to only when ODRUniquingDebugTypes is enabled
pcc accepted this revision.Jun 11 2018, 12:42 PM


262–265 ↗(On Diff #150803)

This could be moved inside the if (!IsUniqued) block.

This revision is now accepted and ready to land.Jun 11 2018, 12:42 PM
tejohnson accepted this revision.Jun 20 2018, 8:13 AM

LGTM - this seems consistent with the fix made in D26212, we're just hitting the issue at a different point during type mapping.

This revision was automatically updated to reflect the committed changes.