Add unit test for CloneModule and #dbg_label

[PietroGhg]

This PR adds a unit test for llvm::CloneModule, to make sure that #dbg_label and relative metadata nodes are cloned correctly.

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-llvm-transforms

Author: None (PietroGhg)

Changes

This PR adds a unit test for llvm::CloneModule, to make sure that #dbg_label and relative metadata nodes are cloned correctly.

---

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

1 Files Affected:

• (modified) llvm/unittests/Transforms/Utils/CloningTest.cpp (+38)

diff --git a/llvm/unittests/Transforms/Utils/CloningTest.cpp b/llvm/unittests/Transforms/Utils/CloningTest.cpp
index 6f4e860d60468..ded1841ef7d21 100644
--- a/llvm/unittests/Transforms/Utils/CloningTest.cpp
+++ b/llvm/unittests/Transforms/Utils/CloningTest.cpp
@@ -1122,4 +1122,42 @@ TEST_F(CloneModule, IFunc) {
   EXPECT_EQ("resolver", Resolver->getName());
   EXPECT_EQ(GlobalValue::PrivateLinkage, Resolver->getLinkage());
 }
+
+TEST_F(CloneModule, CloneDbgLabel) {
+  LLVMContext Context;
+
+  std::unique_ptr<Module> M = parseIR(
+    Context,
+    R"M(
+define void @noop(ptr nocapture noundef writeonly align 4 %dst) local_unnamed_addr !dbg !3 {
+entry:
+  %call = tail call spir_func i64 @foo(i32 noundef 0)
+    #dbg_label(!11, !12)
+  store i64 %call, ptr %dst, align 4
+  ret void
+}
+
+declare i64 @foo(i32 noundef) local_unnamed_addr
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!2}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C99, file: !1, producer: "clang version 19.0.0git", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug)
+!1 = !DIFile(filename: "<stdin>", directory: "foo")
+!2 = !{i32 2, !"Debug Info Version", i32 3}
+!3 = distinct !DISubprogram(name: "noop", scope: !4, file: !4, line: 17, type: !5, scopeLine: 17, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !9)
+!4 = !DIFile(filename: "file", directory: "foo")
+!5 = !DISubroutineType(types: !6)
+!6 = !{null, !7}
+!7 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !8, size: 64)
+!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!9 = !{}
+!11 = !DILabel(scope: !3, name: "foo", file: !4, line: 23)
+!12 = !DILocation(line: 23, scope: !3)
+)M");
+
+ ASSERT_FALSE(verifyModule(*M, &errs()));
+ auto NewM = llvm::CloneModule(*M);
+ EXPECT_FALSE(verifyModule(*NewM, &errs()));
+}
 }

[PietroGhg]

Hi @SLTozer, this test case is related to #91447 (and follow up PRs). For reference, the test case currently fails with DICompileUnit not listed in llvm.dbg.cu.

[SLTozer]

This largely LGTM at a glance - is there a reason for this to be in a separate PR to the patch that it depends on though? Normally we'd expect them to be merged in the same commit.

[hvdijk]

If it had been my own test, I would have included it in my earlier PR, but it's Pietro's test, so I think it's fairest to have him listed as the author, and Git makes that easiest by having separate PRs. But if you prefer, we can merge them.

[SLTozer]

If possible, it'd be better to have them in the same commit with a "Co-authored-by" tag; it's not the worst thing if the fix lands first and then the test, but if the functional commit causes some further error and gets reverted after the unit test has landed, then the unit test will still be present and will start failing because of the revert. It's not a common scenario, but using a single commit reduces the risk of confusion or surprising behaviour.

[hvdijk]

That's a fair point, and Pietro had said offline he's okay with merging the two PRs, so I've updated #91456 to include this.