dzhidzhoev wrote: > 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).
But the notion of "abstract" subprogram pops up only during DWARF generation, doesn’t it? On the level of LLVM IR, we don’t have a way to distinguish between abstract and concrete DISubprogram, if I get it right. > 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)) It seems something similar is done for declarations of composite type member subprograms, according to https://llvm.org/docs/LangRef.html#disubprogramdeclaration : > When spFlags: DISPFlagDefinition is not present, subprograms describe a > declaration in the type tree as opposed to a definition of a function. In > this case, the declaration field must be empty. If the scope is a composite > type with an ODR identifier: and that does not set flags: DIFwdDecl, then the > subprogram declaration is uniqued based only on its linkageName: and scope:. https://github.com/llvm/llvm-project/pull/142166 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
