[PATCH] D147620: [DebugInfo] Keep the CU consistent for operating `DISubprogram`.

[DianQK via Phabricator via llvm-commits]

DianQK added inline comments.


================
Comment at: llvm/test/DebugInfo/Generic/cross-cu.ll:40-62
+!1 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !2, producer: "clang LLVM (rustc version 1.70.0-nightly (ec2f40c6b 2023-03-30))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3, splitDebugInlining: false)
+!2 = !DIFile(filename: "src/lib.rs/@/3jkrl8oz9knrf4o4", directory: "/home/npopov/repos/test")
+!3 = !{}
+!4 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !5, producer: "clang LLVM (rustc version 1.70.0-nightly (ec2f40c6b 2023-03-30))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3, globals: !6, splitDebugInlining: false)
+!5 = !DIFile(filename: "src/lib.rs/@/4r9uiw0o66d13q4b", directory: "/home/npopov/repos/test")
+!6 = !{!7}
+!7 = !DIGlobalVariableExpression(var: !8, expr: !DIExpression())
----------------
dblaikie wrote:
> OK, so from the description in the other inline comment - I take it you're dealing with the situation here, where:
> 
> `!23` (`DISubprogram` for `alloc::alloc::Global::alloc_impl`) is defined in CU `!1`
> `!8` that also, indirectly, references the type is in CU `!4`
> 
> Yeah, I think the bug here is that you shouldn't have member function definitions directly associated with DICompositeTypes - they should indirect through a declaration of the function.
> 
> Otherwise we'll inevitably end up in impossible situations - where we can't define the type in every translation unit that defines one of the member functions (or other references) to the type.
> 
> Types are intentionally not attached to a CU because they exist across the whole program - so we need to be able to reference them from anywhere/lazily create them in whatever CU we need, generally.
> 
> If you've got similar metadata from Swift, I'd like to take a look/talk to the Apple/Swift folks about this.
> 
> But, yeah, generally, I don't think this IR is OK/supportable as-is. It should have a declaration of the function - so that the function definition can appear in a CU distinct from the definition of the type. So the function definition can stay in the CU that defined it.
Thank you for clarifying the issue.
Maybe @aprantl could come and take a look at Swift?

I'm glad to check out the Rust-related implementation. I only know a little bit about Rust. It may take some time.
Do you think it is appropriate to submit this patch as a workaround? We can revert it before LLVM 17 is released.
This change does not appear to affect C++ debug info generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147620