Skip to content

[DebugInfo][LoopUnroll] Preserve DebugLocs on optimized cond branches #114225

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.

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 1 commit into from
Nov 8, 2024

Conversation

SLTozer
Copy link
Contributor

@SLTozer SLTozer commented Oct 30, 2024

This patch fixes a simple error where as part of loop unrolling we optimize conditional loop-exiting branches into unconditional branches when we know that they will or won't exit the loop, but does not propagate the source location of the original branch to the new one.

Found using #107279.

This patch fixes a simple error where as part of loop unrolling we optimize
conditional loop-exiting branches into unconditional branches when we know that
they will or won't exit the loop, but does not propagate the source location of
the original branch to the new one.
@llvmbot
Copy link
Member

llvmbot commented Oct 30, 2024

@llvm/pr-subscribers-llvm-transforms

@llvm/pr-subscribers-debuginfo

Author: Stephen Tozer (SLTozer)

Changes

This patch fixes a simple error where as part of loop unrolling we optimize conditional loop-exiting branches into unconditional branches when we know that they will or won't exit the loop, but does not propagate the source location of the original branch to the new one.


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

2 Files Affected:

  • (modified) llvm/lib/Transforms/Utils/LoopUnroll.cpp (+2-1)
  • (added) llvm/test/Transforms/LoopUnroll/preserve-branch-debuglocs.ll (+52)
diff --git a/llvm/lib/Transforms/Utils/LoopUnroll.cpp b/llvm/lib/Transforms/Utils/LoopUnroll.cpp
index b90addcef69e6e..4cbbac07915fbe 100644
--- a/llvm/lib/Transforms/Utils/LoopUnroll.cpp
+++ b/llvm/lib/Transforms/Utils/LoopUnroll.cpp
@@ -883,7 +883,8 @@ llvm::UnrollLoop(Loop *L, UnrollLoopOptions ULO, LoopInfo *LI,
     DeadSucc->removePredecessor(Src, /* KeepOneInputPHIs */ true);
 
     // Replace the conditional branch with an unconditional one.
-    BranchInst::Create(Dest, Term->getIterator());
+    auto *BI = BranchInst::Create(Dest, Term->getIterator());
+    BI->setDebugLoc(Term->getDebugLoc());
     Term->eraseFromParent();
 
     DTUpdates.emplace_back(DominatorTree::Delete, Src, DeadSucc);
diff --git a/llvm/test/Transforms/LoopUnroll/preserve-branch-debuglocs.ll b/llvm/test/Transforms/LoopUnroll/preserve-branch-debuglocs.ll
new file mode 100644
index 00000000000000..623fb68c784fe7
--- /dev/null
+++ b/llvm/test/Transforms/LoopUnroll/preserve-branch-debuglocs.ll
@@ -0,0 +1,52 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --check-globals all --version 5
+; RUN: opt < %s -passes=loop-unroll -S | FileCheck %s
+; RUN: opt < %s -passes=loop-unroll-full -S | FileCheck %s
+
+;; Loop Unrolling should preserve the DebugLocs of conditional branches that get
+;; optimized into unconditional branches.
+
+define i32 @_ZeqRK4int3S1_() {
+; CHECK-LABEL: define i32 @_ZeqRK4int3S1_() {
+; CHECK-NEXT:  [[ENTRY:.*:]]
+; CHECK-NEXT:    br label %[[FOR_BODY:.*]]
+; CHECK:       [[FOR_COND:.*]]:
+; CHECK-NEXT:    br label %[[CLEANUP:.*]], !dbg [[DBG3:![0-9]+]]
+; CHECK:       [[FOR_BODY]]:
+; CHECK-NEXT:    br i1 false, label %[[FOR_COND]], label %[[CLEANUP]]
+; CHECK:       [[CLEANUP]]:
+; CHECK-NEXT:    ret i32 0
+;
+entry:
+  br label %for.body
+
+for.cond:                                         ; preds = %for.body
+  br i1 false, label %cleanup, label %for.body, !dbg !3
+
+for.body:                                         ; preds = %for.cond, %entry
+  br i1 false, label %for.cond, label %cleanup
+
+cleanup:                                          ; preds = %for.body, %for.cond
+  ret i32 0
+}
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!2}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 20.0.0git", isOptimized: true, runtimeVersion: 0, emissionKind: NoDebug)
+!1 = !DIFile(filename: "test.cpp", directory: "/tmp")
+!2 = !{i32 2, !"Debug Info Version", i32 3}
+!3 = !DILocation(line: 304, column: 2, scope: !4)
+!4 = distinct !DILexicalBlock(scope: !5, file: !1, line: 304, column: 2)
+!5 = distinct !DISubprogram(name: "operator==", linkageName: "_ZeqRK4int3S1_", scope: !1, file: !1, line: 302, type: !6, scopeLine: 303, spFlags: DISPFlagDefinition, unit: !0)
+!6 = distinct !DISubroutineType(types: !7)
+!7 = !{}
+;.
+; CHECK: [[META0:![0-9]+]] = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: [[META1:![0-9]+]], producer: "{{.*}}clang version {{.*}}", isOptimized: true, runtimeVersion: 0, emissionKind: NoDebug)
+; CHECK: [[META1]] = !DIFile(filename: "test.cpp", directory: {{.*}})
+; CHECK: [[META2:![0-9]+]] = !{i32 2, !"Debug Info Version", i32 3}
+; CHECK: [[DBG3]] = !DILocation(line: 304, column: 2, scope: [[META4:![0-9]+]])
+; CHECK: [[META4]] = distinct !DILexicalBlock(scope: [[META5:![0-9]+]], file: [[META1]], line: 304, column: 2)
+; CHECK: [[META5]] = distinct !DISubprogram(name: "operator==", linkageName: "_ZeqRK4int3S1_", scope: [[META1]], file: [[META1]], line: 302, type: [[META6:![0-9]+]], scopeLine: 303, spFlags: DISPFlagDefinition, unit: [[META0]])
+; CHECK: [[META6]] = distinct !DISubroutineType(types: [[META7:![0-9]+]])
+; CHECK: [[META7]] = !{}
+;.

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.

Looks good to me, thanks! 😄

Did you discover this issue using your recent location debugging features...? If so, perhaps a label or comment in the PR would allow tracking bugs found via that work. Just a suggestion, feel free to ignore.

@SLTozer
Copy link
Contributor Author

SLTozer commented Oct 30, 2024

Did you discover this issue using your recent location debugging features...? If so, perhaps a label or comment in the PR would allow tracking bugs found via that work. Just a suggestion, feel free to ignore.

Yes, do you have any suggestions for how to unobtrusively make the set of PRs more searchable?

@dwblaikie
Copy link
Collaborator

Did you discover this issue using your recent location debugging features...? If so, perhaps a label or comment in the PR would allow tracking bugs found via that work. Just a suggestion, feel free to ignore.

Yes, do you have any suggestions for how to unobtrusively make the set of PRs more searchable?

if you've got a PR or issue for the overarching thing, you can probably just mention that by number with #XXXX in each of these fixes to link back to the main thing - not the /most/ searchable thing (I don't know how to quickly then make a list of all the things that reference an issue) but at least they will be available in one page (the backlinks will create updates/be noted on the main issue - just not in a neat and tidy list, but in part of the update stream of comments, etc)

@jryans
Copy link
Member

jryans commented Oct 30, 2024

if you've got a PR or issue for the overarching thing, you can probably just mention that by number with #XXXX in each of these fixes to link back to the main thing

Yeah, either mentioning some phrase (e.g. "DebugLoc coverage tracking") that you include in the description of all related PRs or linking to some top-level PR / issue should work. You can then search all PRs for "DebugLoc coverage" or "#XXXX" to produce a list.

@SLTozer SLTozer merged commit 92e0fb0 into llvm:main Nov 8, 2024
11 checks passed
Groverkss pushed a commit to iree-org/llvm-project that referenced this pull request Nov 15, 2024
…llvm#114225)

This patch fixes a simple error where as part of loop unrolling we
optimize conditional loop-exiting branches into unconditional branches
when we know that they will or won't exit the loop, but does not
propagate the source location of the original branch to the new one.

Found using llvm#107279.
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.

5 participants