Previously we missed cloning metadata on function declarations because
we don't call CloneFunctionInto() on declarations in CloneModule().
Details
- Reviewers
dexonsmith - Commits
- rG512534bc16d2: [Cloning] Clone metadata on function declarations
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
Thanks, that rings a bell now.
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 | ||
---|---|---|
148–151 | 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. |
I was initially worried about this skipping the DebugInfoFinder logic mentioned in this comment from CloneFunctionInto:
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.