This is an archive of the discontinued LLVM Phabricator instance.

[MachineLICM] Assert that locations from debug insts are not lost
ClosedPublic

Authored by vsk on May 27 2020, 2:17 PM.

Details

Summary

Assert that MachineLICM does not move a debug instruction and then drop
its debug location. Later passes require each debug instruction to have
a location.

Testing: check-llvm, clang stage2 RelWithDebInfo build (x86_64)

Diff Detail

Event Timeline

vsk created this revision.May 27 2020, 2:17 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 27 2020, 2:17 PM

As we discussed offline, I think the assertion makes sense, so LGTM. It's good to catch violations while we decide what to do with hoisting (what are the semantics et similia).
Do you think it's worth writing a verifier check to make sure that DBG_VALUE(s) when hoisted have always a location -- otherwise the MIR is considered illformed? I can do that, but I would like to have your opinion on it.

vsk added a comment.May 27 2020, 3:49 PM

Do you think it's worth writing a verifier check to make sure that DBG_VALUE(s) when hoisted have always a location -- otherwise the MIR is considered illformed? I can do that, but I would like to have your opinion on it.

That's a good point. I went ahead and took a stab at this: https://reviews.llvm.org/D80670.

jmorse accepted this revision.May 28 2020, 10:44 AM

LGTM -- I'd suggest that the assertion messages could become something like "Shouldn't be hoisting debug instructions" or similar. IMO, as well as the matter of dropping DebugLocs, debug instructions should (almost?) never appears as a candidate to be moved around like another instruction.

This revision is now accepted and ready to land.May 28 2020, 10:44 AM

LGTM -- I'd suggest that the assertion messages could become something like "Shouldn't be hoisting debug instructions" or similar. IMO, as well as the matter of dropping DebugLocs, debug instructions should (almost?) never appears as a candidate to be moved around like another instruction.

While I agree with you in theory, the classical counterexample for this claim is merging successors in predecessors, or all the CFG'ish transformations that SimplifyCFG is very good at doing. In that case you just move full blocks around and the likelihood of moving DebugInfo around is very high.

LGTM -- I'd suggest that the assertion messages could become something like "Shouldn't be hoisting debug instructions" or similar. IMO, as well as the matter of dropping DebugLocs, debug instructions should (almost?) never appears as a candidate to be moved around like another instruction.

While I agree with you in theory, the classical counterexample for this claim is merging successors in predecessors, or all the CFG'ish transformations that SimplifyCFG is very good at doing. In that case you just move full blocks around and the likelihood of moving DebugInfo around is very high.

LICM and MachineLICM really don't quite suffer from this problem, as you already pointed out.

vsk added a comment.May 28 2020, 1:33 PM

LGTM -- I'd suggest that the assertion messages could become something like "Shouldn't be hoisting debug instructions" or similar. IMO, as well as the matter of dropping DebugLocs, debug instructions should (almost?) never appears as a candidate to be moved around like another instruction.

Thanks, I'll fix this before committing.