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

[Reid Kleckner via llvm-commits]

================
@@ -89,9 +90,14 @@ has a location with an accurate scope attached, and b) to prevent misleading
 single-stepping (or breakpoint) behavior. Often, merged instructions are memory
 accesses which can trap: having an accurate scope attached greatly assists in
 crash triage by identifying the (possibly inlined) function where the bad
-memory access occurred. This rule is also meant to assist SamplePGO by banning
-scenarios in which a sample of a block containing a merged instruction is
-misattributed to a block containing one of the instructions-to-be-merged.
+memory access occurred. 
+
+For SamplePGO, it is often beneficial to retain an arbitrary but deterministic
+location instead of discarding line and column information as part of merging.
+In particular, loss of location information for calls inhibit optimizations 
+such as indirect call promotion. This behavior can be optionally enabled until
+support for accurately representing merged instructions in the line table is
+implemented. 
----------------
rnk wrote:

Are branch instruction locations also critical? I've had more conversations with other sample PGO folks, and my mental model is that PGO constructs branch weights from LBR (Last Branch Record) counters. So, the key to getting accurate branch weights is not having deterministic, distinct source locations on every instruction in the basic block, it's tracking deterministic, distinct source locations on every branch instruction. I think it turns out that, in practice, branch instructions are control instructions, so they tend to either folded away, duplicated in order (inlining, unswitching), or left alone. It doesn't really make sense to speculate a branch instruction. The folding we do just needs to be extremely careful about tracking slocs, just like it has to care about updating branch weights.

If that's accurate, I think it would be helpful to document that maintaining deterministic and distinct source locations are what's important for sample PGO. I think this would go a long way to helping motivate why we can safely retain more source locations on out-of-order instructions without negatively impacting sample PGO results.

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