[PATCH] D135267: [DWARF] Share across CUs only when order free

[DianQK via Phabricator via llvm-commits]

DianQK added a comment.

@dblaikie 
Following your case, I created one swift example.

But let's revisit the C++ example back.
I found the `main.cpp` CU is not use `DISubprogram(name: "f1"...)`.
It only uses `DILocation`:

  define dso_local noundef i32 @main() #0 !dbg !10 {
    %1 = alloca %struct.t1, align 1
    call void @_ZN2t12f1Ev(%struct.t1* noundef nonnull align 1 dereferenceable(1) %1), !dbg !15
    ret i32 0, !dbg !16
  }
  
  !10 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 7, type: !11, scopeLine: 7, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !14)
  !15 = !DILocation(line: 8, column: 8, scope: !10)

Use single `main.cpp`(All in one file) or link `t1.cpp` and `main.cpp` for are same result.
Everything is fine. I think the declaration is irrelevant.

Hmm, in swift, it's the same as C++.

  struct t1 {
      func f1() {}
  }
  t1().f1()



  define protected i32 @main(i32 %0, i8** %1) #0 !dbg !35 {
    %3 = bitcast i8** %1 to i8*
    call swiftcc void @"$s4demo2t1VACycfC"(), !dbg !47
    call swiftcc void @"$s4demo2t1V2f1yyF"(), !dbg !49
    ret i32 0, !dbg !49
  }
  
  !35 = distinct !DISubprogram(name: "main", linkageName: "main", scope: !5, file: !1, line: 1, type: !36, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
  !48 = distinct !DILexicalBlock(scope: !35, file: !1, line: 9, column: 1)
  !49 = !DILocation(line: 9, column: 6, scope: !48)

I fallback to my case and remove `Hashable`:
`t1.swift`:

  struct t1 {
      func f1() {}
  }

`main.swift`

  let _t1 = t1()
  _t1.f1()

It created `DICompositeType(tag: DW_TAG_structure_type, name: "t1" ...)` in `t1.ll` and `main.ll`.

`main.ll`:

  !0 = distinct !DICompileUnit(language: DW_LANG_Swift, file: !1, producer: "Swift version 5.6 (swift-5.6-RELEASE)", isOptimized: true, runtimeVersion: 5, emissionKind: FullDebug, enums: !2, globals: !3, imports: !10)
  !3 = !{!4}
  !4 = !DIGlobalVariableExpression(var: !5, expr: !DIExpression(DW_OP_constu, 0, DW_OP_stack_value))
  !5 = distinct !DIGlobalVariable(name: "_t1", scope: !6, file: !1, line: 1, type: !7, isLocal: true, isDefinition: true)
  !7 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !8)
  !8 = !DICompositeType(tag: DW_TAG_structure_type, name: "t1", scope: !6, file: !9, elements: !2, runtimeLang: DW_LANG_Swift, identifier: "$s4demo2t1VD")

`t1.ll`:

  !0 = distinct !DICompileUnit(language: DW_LANG_Swift, file: !1, producer: "Swift version 5.6 (swift-5.6-RELEASE)", isOptimized: true, runtimeVersion: 5, emissionKind: FullDebug, enums: !2, imports: !3)
  !32 = !DICompositeType(tag: DW_TAG_structure_type, name: "t1", scope: !5, file: !1, elements: !2, runtimeLang: DW_LANG_Swift, identifier: "$s4demo2t1VD")

DwarfDebug.cpp#L1221 <https://github.com/llvm/llvm-project/blob/9e6d1f4b5d393b8d74640c72b94ccc23ed4ee885/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp#L1221> always puts the  `DW_TAG_structure_type("t1")`  inside the CU of `main.swift`, then all member functions are put inside this CU/`DW_TAG_structure_type`.

You are right. `DW_TAG_structure_type("t1")`  doesn't have to be inside in the CU of `t1.swift`.
But if I add `Hashable`, it will create a function in the CU of `t1.swift` that needs a function inside of the `DW_TAG_structure_type("t1")` in the CU of `main.swift`.

> I don't know how to create a similar IR in C++.

D135114 <https://reviews.llvm.org/D135114> has fixed fine. We can use any DIE in any CU. (But this does not solve the "no mapping for range" problem mentioned earlier.)

I will check about the Rust language later. For now, I think we should support these new cases.
Because these IRs look fine and maybe many language use like this case.

> Sorry, I'm new to DebugInfo (also LLVM), but I will try to improve my term standards.

F24837465: swift.zip <https://reviews.llvm.org/F24837465>


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135267/new/

https://reviews.llvm.org/D135267