DebugInfo was incorrectly retained for sinks and post-register allocation hoists in the machine LICM pass. This diff is intended to address the problem.
Can you explain why the sunk instruction's location is considered incorrect? I would have naively assumed that for profiling particularly, you would want to retain the original location to ensure that it is counted.
Can a DBG_VALUE ever be hoisted out of a loop? In that case this would delete the inline info from the intrinsic and attribute the inlined variable to the wrong function.
I should think profiling is mostly concerned about control flow, and a sampling profiler would infer control flow from the source location of the instruction. If you sink an instruction but retain the original source location, a hit would be tallied for the moved-from block not the moved-to block, but the moved-to block would be more appropriate. I might be misunderstanding the profiler's needs though, this is not an area I am super familiar with.
I feel like we should start a HowToUpdateDebugInfo.rst document where we document the expected behavior for various code transformations and what we expect the debug info to look like afterwards...