[llvm] r203982 - Debug Info: Fix LTO type uniquing for C++ member declarations

David Blaikie dblaikie at gmail.com
Fri Mar 14 18:39:14 PDT 2014


On Fri, Mar 14, 2014 at 6:21 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On Mar 14, 2014, at 18:09, David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Fri, Mar 14, 2014 at 4:08 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>> Author: adrian
>>> Date: Fri Mar 14 18:08:25 2014
>>> New Revision: 203982
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=203982&view=rev
>>> Log:
>>> Debug Info: Fix LTO type uniquing for C++ member declarations
>>> based on the ODR.
>>
>> Could we just use the same DIRef machinery for functions too?
>
> see the second-to-next paragraph :-)
>
>>
>>> This adds an OdrMemberMap to DwarfDebug which is used to unique C++
>>> member function declarations based on the unique identifier of their
>>> containing class and their mangled name.
>>
>> Why not just the mangled name? (see above - using the same DIRef machinery)
>
> Do all member functions that have linkage get unique names across all compilation units?

That's the notion - though Clang doesn't consistently attach the
linkage name to them in the metadata (sometimes we put linkage names
ot link-local functions, and sometimes omit it on functions with
linkage... )

> If so, that will work. Good point.
>
>>> We can't use the usual DIRef mechanism here because DIScopes are indexed
>>> using their entire MDNode, including decl_file and decl_line, which need
>>> not be unique (see testcase).
>>
>> OK - not sure what you mean by this. I guess you mean DISubprogram is
>> a DIScope - but we could change the DISubprogram references without
>> changing the way that all DIScopes were referenced maybe? I'm not
>> sure.
>>
>> Would be worth discussing this a bit, I hope...
>
> The problem is that it is not always legal to unique subprograms -- now, I guess we could add an additional UID field to each DIScope (or better DISubprogram) that is only populated when it's legal to do so. I'll ponder this a bit.

That would be the mangled name of the function (if the function has
linkage - though I'm bad at the precise linkage terminology) - same
way we do this for types (only using the unique ID for types that are
not local to the translation unit)

- David



More information about the llvm-commits mailing list