This is an archive of the discontinued LLVM Phabricator instance.

[Cloning] Clone metadata on function declarations
ClosedPublic

Authored by aeubanks on Nov 12 2021, 3:49 PM.

Details

Summary

Previously we missed cloning metadata on function declarations because
we don't call CloneFunctionInto() on declarations in CloneModule().

Diff Detail

Event Timeline

aeubanks created this revision.Nov 12 2021, 3:49 PM
aeubanks requested review of this revision.Nov 12 2021, 3:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2021, 3:49 PM

Huh... when did metadata get added to function declarations? I'm not sure what the semantics of those are supposed to be. I seem to remember that been left out when metadata was added for definitions.

Huh... when did metadata get added to function declarations?

Since D21052

dexonsmith accepted this revision.Dec 1 2021, 3:31 PM

Huh... when did metadata get added to function declarations?

Since D21052

Thanks, that rings a bell now.

ping

LGTM! I left a rambling comment inline but I'm not sure there's anything to be done with it.

llvm/lib/Transforms/Utils/CloneModule.cpp
143–146

I was initially worried about this skipping the DebugInfoFinder logic mentioned in this comment from CloneFunctionInto:

// Duplicate the metadata that is attached to the cloned function.
// Subprograms/CUs/types that were already mapped to themselves won't be
// duplicated.
SmallVector<std::pair<unsigned, MDNode *>, 1> MDs;
OldFunc->getAllMetadata(MDs);
for (auto MD : MDs) {
  NewFunc->addMetadata(MD.first, *MapMetadata(MD.second, VMap, RemapFlag,
                                              TypeMapper, Materializer));
}

Looking at that logic closely, I think it's okay to skip. If the new location is a different module, the DebugInfoFinder is only used for walking the instructions (of which a declaration has none). Only if it's in the same module does it walk the function's attachments.

I thought about trying to put that logic in a function that would be reused here (but be a no-op) in case the logic changes over time. But given that this is a new module, I think it's really unlikely to be useful and would be distracting.

I wonder if there's a comment that should be left somewhere, but I'm not sure what it would say. Maybe it's just obvious that for a new module you don't want special logic like that.

This revision is now accepted and ready to land.Dec 1 2021, 3:31 PM
This revision was automatically updated to reflect the committed changes.