[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

[Jeremy Morse via cfe-commits]

jmorse wrote:

Hadn't realised lambda types will pop up everywhere, the cost might be too high. I'll test with building clang and our internal codebases to see if the fix works and what the cost is.

> Surely if we can compute a unique mangled name for this local class, we should use it as the identifier and merge it.

Indeed, it's not the ODR-uniquing per-se that's causing the trouble here, it's the fact that we do not merge together the DISubprograms that are the containing scope for that type upon module linking. I'm not familiar with the design decisions behind that, but a courtesy glance suggests it's important to identify the compilation unit that a DISubprogram instance came from. We're then stuck with multiple DISubprograms and a single DIComposite type referring to one of them as being its scope, which presumably breaks a lot of assumptions.

Perhaps a worthwhile direction is separating DISubprograms into abstract and definition portions, much like DWARF does, which would allow us to put these types into the declaration and have a well defined scope hierarchy: types that get uniqued refer to the abstract-DISubprogram for their lexical scope. Perhaps that's can be achieved with the existing distinction between definition DISubprograms and "declaration" DISubprograms? A quick survey of callers to `DISubprogram::getDefinition` and `isDefinition` indicates there aren't many decisions made throughout LLVM based on the definition/declaration split, and there are comments in LLVMContextImpl.h suggesting declaration-DISubprograms are used in ODR'd types too.

If we took that route, the scope-chain would still become a tree of scopes instead of distinct chains, and we would still need to fix the problem of CodeGen LexicalScopes encountering the abstract/declaration DISubprogram. However, I think we'd have the reasonable solution of mapping declaration-DISubprograms in a function to their definition-DISubprogram (assuming the definition had been found already), which is much more reliable than seeking a DISubprogram by name or something.

https://github.com/llvm/llvm-project/pull/75385