Skip to content

Conversation

SLTozer
Copy link
Contributor

@SLTozer SLTozer commented Sep 9, 2025

When merging DILocations, we prefer to use DebugLoc::getMergedLocation when possible to better preserve DebugLoc coverage tracking information through transformations (as conversion to DILocations drops all coverage tracking data). Currently, DebugLoc::getMergedLocation checks to see if either DebugLoc is empty and returns it directly if so, to propagate that DebugLoc's coverage tracking data to the merged location; however, it only checks whether either location is valid, not whether they are annotated.

This is significant because an annotated location is not a bug, while an empty unannotated location may be one; therefore, we check to see if either location is unannotated, and prefer to return that location if it exists rather than an annotated one.

This change is NFC outside of DebugLoc coverage tracking builds.

When merging DILocations, we prefer to use DebugLoc::getMergedLocation when
possible to better preserve DebugLoc coverage tracking information through
transformations (as conversion to DILocations drops all coverage tracking
data). Currently, DebugLoc::getMergedLocation checks to see if either
DebugLoc is empty and returns it directly if so, to propagate that
DebugLoc's coverage tracking data to the merged location; however, it only
checks whether either location is valid, not whether they are annotated.

This is significant because an annotated location is not a bug, while an
empty unannotated location may be one; therefore, we check to see if either
location is unannotated, and prefer to return that location if it exists
rather than an annotated one.

This change is NFC outside of DebugLoc coverage tracking builds.
@llvmbot
Copy link
Member

llvmbot commented Sep 9, 2025

@llvm/pr-subscribers-llvm-ir

@llvm/pr-subscribers-debuginfo

Author: Stephen Tozer (SLTozer)

Changes

When merging DILocations, we prefer to use DebugLoc::getMergedLocation when possible to better preserve DebugLoc coverage tracking information through transformations (as conversion to DILocations drops all coverage tracking data). Currently, DebugLoc::getMergedLocation checks to see if either DebugLoc is empty and returns it directly if so, to propagate that DebugLoc's coverage tracking data to the merged location; however, it only checks whether either location is valid, not whether they are annotated.

This is significant because an annotated location is not a bug, while an empty unannotated location may be one; therefore, we check to see if either location is unannotated, and prefer to return that location if it exists rather than an annotated one.

This change is NFC outside of DebugLoc coverage tracking builds.


Full diff: https://github.com/llvm/llvm-project/pull/157707.diff

1 Files Affected:

  • (modified) llvm/lib/IR/DebugLoc.cpp (+12-3)
diff --git a/llvm/lib/IR/DebugLoc.cpp b/llvm/lib/IR/DebugLoc.cpp
index 79c5b896f8f25..01dafcab94ce9 100644
--- a/llvm/lib/IR/DebugLoc.cpp
+++ b/llvm/lib/IR/DebugLoc.cpp
@@ -181,10 +181,19 @@ DebugLoc DebugLoc::getMergedLocations(ArrayRef<DebugLoc> Locs) {
   return Merged;
 }
 DebugLoc DebugLoc::getMergedLocation(DebugLoc LocA, DebugLoc LocB) {
-  if (!LocA)
-    return LocA;
-  if (!LocB)
+  if (!LocA || !LocB) {
+    // If coverage tracking is enabled, prioritize returning empty non-annotated
+    // locations to empty annotated locations.
+#if LLVM_ENABLE_DEBUGLOC_TRACKING_COVERAGE
+    if (!LocA && LocA.getKind() == DebugLocKind::Normal)
+      return LocA;
+    if (!LocB && LocB.getKind() == DebugLocKind::Normal)
+      return LocB;
+#endif // LLVM_ENABLE_DEBUGLOC_TRACKING_COVERAGE
+    if (!LocA)
+      return LocA;
     return LocB;
+  }
   return DILocation::getMergedLocation(LocA, LocB);
 }
 

Copy link
Member

@jryans jryans left a comment

Choose a reason for hiding this comment

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

Seems reasonable to me! 😄

@SLTozer SLTozer merged commit 79e9317 into llvm:main Sep 10, 2025
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants