[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #142166)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> (Transparency, I wrote some of the code in the PR so dunno if I should review it,)
> 
> > I /think/ function-local types need to go in definitions - in /abstract/ definitions if they exist (not in the inlined instances or concrete out of line instances).
> 
> I think this highlights the difference in my thinking -- I've been treating "declaration" DISubprograms like they're actually "abstract" DISubprograms (they're very similar in my mind). As far as I'm aware we don't have any entities in LLVM-IR metadata to represent abstract DISubprograms, and from `DwarfCompileUnit::constructAbstractSubprogramScopeDIE` it looks like we just construct them on-the-fly when they become necessary. Would you see having a `DIAbstractSubprogram` metadata node, or a new subprogram flag, as being the correct refinement?

*goes to see what the DWARF for inlining looks like*

so inlined instances refer to the same distinct DISubprogram as a function definition at the moment.

How does this work for LTO? (we'd want all inlined instances to refer to a singular abstract definition) Yeah, looks like that's broken (the abstract origins are not shared - they're duplicated in every translation unit).

We should fix that. We have mangled names on functions like we do for types, so we could use the same approach to deduplicate them via mangled name as a key? (for types this mangled name field was introduced specifically as a deduplication key (I think initially for type units, then for LTO merging, but maybe it was the other way around) - currently the linkage name for functions isn't a load bearing key, but it could become one, or perhaps needs to be a distinct key compared to the mangled name - in the case of internal functions/types they might have a mangled name, but not allow deduplication (for internal linkage types, we omit the mangled name/deduplication key))

If that's an infeasibly large project at this time and we want to take on some technical debt to address the ODR type in a non-uniqued entity issue, yeah, guess we could put them on the declaration - but it does feel like it's going to be awkward/painful so long as that sticks around & we'd want to fix the other thing (shared abstract origins in LTO) anyway, probably?


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