This is an archive of the discontinued LLVM Phabricator instance.

Make it illegal for two Functions to point to the same DISubprogram
ClosedPublic

Authored by aprantl on May 8 2017, 12:57 PM.

Details

Summary

As recently discussed on llvm-dev [1], this patch makes it illegal for two Functions to point to the same DISubprogram and updates FunctionCloner to also clone the debug info of a function to conform to the new requirement. To simplify the implementation it also factors out the creation of inlineAt locations from the Inliner into a general-purpose utility in DILocation.

[1] http://lists.llvm.org/pipermail/llvm-dev/2017-May/112661.html

Diff Detail

Repository
rL LLVM

Event Timeline

aprantl created this revision.May 8 2017, 12:57 PM
dblaikie accepted this revision.May 8 2017, 1:27 PM

Looks pretty good to me

lib/IR/DebugLoc.cpp
167 ↗(On Diff #98194)

Probably not need to explicitly state the return type here, unless you particularly like/want to do so?

lib/Transforms/Utils/CloneFunction.cpp
131 ↗(On Diff #98194)

Is this ever not true? I guess it could be if CloneFunction is used to clone from one Module to another? is that a thing that happens?

171–172 ↗(On Diff #98194)

Unrelated formatting - probably revert that.

unittests/Transforms/Utils/Cloning.cpp
364 ↗(On Diff #98194)

EXPECT_NE ?

391–392 ↗(On Diff #98194)

I don't really understand why this change is here - could you explain it?

I guess the actual change you made to CloneFunction makes the new function look as though the old function was inlined into it? That's a great idea/way to do it! :) (though won't be what I need for the LTO+Fission issue - but perhaps I can use some of the pieces you've built/generalized/etc here)

This revision is now accepted and ready to land.May 8 2017, 1:27 PM
aprantl marked 3 inline comments as done.May 8 2017, 1:45 PM
aprantl added inline comments.
lib/Transforms/Utils/CloneFunction.cpp
131 ↗(On Diff #98194)

This is public LLVM API, so I think we need to brace for every possibility here.

unittests/Transforms/Utils/Cloning.cpp
391–392 ↗(On Diff #98194)

Much simpler: This change is necessary because above, I'm adding an inlined function into OldFunc (line 309ff). DILocation::getInlinedAtScope() returns either the parent function of a regular instruction or the parent of the inlined-at location of an inlined instruction, both of which should be the DISubprogram attached to the function the instruction is part of.

dblaikie added inline comments.May 8 2017, 1:50 PM
unittests/Transforms/Utils/Cloning.cpp
391–392 ↗(On Diff #98194)

Hmm, OK - could you explain more why you're doing that? To test the inlining scope rewriting functionality? That's a good point/something I'll have to deal with as well for the ThinLTO case - the frontend compilation might've already done some inlining... oh, except those won't ever be from another module, so that's easier... unless the module linking messed that up, maybe, and picked the foreign module's version of the subprogram :/ Will have to check/ponder.

But this also raises an interesting question then: what if we did represent function cloning as an act of inlining? That might actually be better? maybe? (I wouldn't do it in this commit, probably better separately)

This revision was automatically updated to reflect the committed changes.

I'm really confused by the entirety of the changes to the CloneFunction parts of this. The whole point of the ValueMapper is to fix up value/metadata references. Why do we need a manual version? Also what's up with the DISubprogram::getDistinct? The ValueMapper will create new distinct nodes as it goes along unless RF_MoveDistinctMDs is set (which it isn't inside CloneFunction). Could the problem perhaps have been an incorrectly unset ModuleLevelChanges flag? I'm seeing a ton of assertion failures after this change. I'll submit an appropriate PR to revert the CloneFunction parts of this.