Skip to content

[DebugInfo] Preserve line and column number when merging debug info. #129960

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Apr 4, 2025
Merged

[DebugInfo] Preserve line and column number when merging debug info. #129960

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
cb23baa
[DebugInfo] Preserve line and column number when merging debug info.
Mar 5, 2025
df04e25
Address comments.
Mar 5, 2025
e43ffd1
Update docs to mention SamplePGO debug info usage.
Mar 14, 2025
ffea531
Fix typo.
Mar 18, 2025
713ae85
Enhance the documentation for SamplePGO.
Mar 24, 2025
4ba8427
Address comments.
Mar 31, 2025
7129758
Fix formatting.
Apr 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 10 additions & 4 deletions llvm/docs/HowToUpdateDebugInfo.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,8 @@ Introduction
============

Certain kinds of code transformations can inadvertently result in a loss of
debug info, or worse, make debug info misrepresent the state of a program.
debug info, or worse, make debug info misrepresent the state of a program. Debug
info availability is also essential for SamplePGO.

This document specifies how to correctly update debug info in various kinds of
code transformations, and offers suggestions for how to create targeted debug
Expand Down Expand Up @@ -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.
Copy link
Collaborator

@rnk rnk Mar 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@snehasish snehasish Mar 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are branch instruction locations also critical?

Yes, though the design of sample attribution mitigates this somewhat by inferring block weight from the max of all instructions in the basic block. Calls are more important since they carry additional metadata apart from their own execution count as noted earlier.

Updated text, ptal.


Examples of transformations that should follow this rule include:

Expand Down
8 changes: 8 additions & 0 deletions llvm/docs/SourceLevelDebugging.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,8 @@ the stored debug information into source-language specific information. As
such, a debugger must be aware of the source-language, and is thus tied to a
specific language or family of languages.

.. _intro_consumers:

Debug information consumers
---------------------------

Expand All @@ -71,6 +73,12 @@ as Visual Studio and WinDBG. LLVM's debug information format is mostly derived
from and inspired by DWARF, but it is feasible to translate into other target
debug info formats such as STABS.

SamplePGO (also known as `AutoFDO <https://gcc.gnu.org/wiki/AutoFDO>`_)
is a variant of profile guided optimizations which uses hardware sampling based
profilers to collect branch frequency data to with low overhead in production
environments. It relies on debug information to associate profile information
to LLVM IR which is then used to guide optimization heuristics.

It would also be reasonable to use debug information to feed profiling tools
for analysis of generated code, or, tools for reconstructing the original
source from generated code.
Expand Down