[llvm] [DebugInfo] Preserve line and column number when merging debug info. (PR #129960)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> Thanks for taking a look @dwblaikie.
> 
> > This seems like a pretty substantial departure from LLVM's documented approach to instruction line information - a policy that was established predominantly as an agreement/unified needs between Google (for profile accuracy) and Sony (for user debuggability/not so "jumpy" stepping).
> 
> We do not intend to change the behaviour for scenarios where users are stepping through the binary. 

That's hard to separate -people still want to debug their production binaries.

> This behaviour is intended to be enabled in production where sample profiles are collected, similar in spirit to `-fdebug-info-for-profiling`. This is the reason why we will keep this gated behind a flag.

`-fdebug-info-for-profiling`, so far, adds extra debug info but doesn't harm/change/remove existing debug info - sounds like we're considering diverging from that, which seems difficult.

> I believe this notion of attribution for AutoFDO is outdated. Today hotness inference for a basic block relies on branch target information. In your example, we would use the debug information attached to the if statement to determine the hotness of the callsites for f2 and f3.

Hrm :/ Sort of following, thanks.

> > Or which cases do benefit?
> 
> Debug info loss on merged indirect calls is particularly important since it disallows indirect call promotion. 

Could you walk me through this in more detail - exactly what DWARF is generated, how does it get consumed, and what decisions are made based on it?


> The net impact of retaining a deterministic version of merged debug info for a large workload is positive. MemProf is a context sensitive profile which is particularly susceptible to loss of debug information on direct and indirect calls. This is part of a broader effort to improve profile quality for AutoFDO and MemProf by addressing missing debug info. I think we will find additional opportunities and once we have a better idea, I can update the documentation and guidance at https://llvm.org/docs/HowToUpdateDebugInfo.html.
> 
> Does that sound reasonable to you?

I'd be inclined to figure out the principles here a bit earlier/somewhat up front, before we make changes. I'm especially concerned about a divergence between what's good for profilers and what's good for humans.


https://github.com/llvm/llvm-project/pull/129960