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

Adrian Prantl aprantl at apple.com
Tue Mar 18 10:51:40 PDT 2014


With more pervasive use of DIRef’s, I could fix this to work without the additional map in r204162.

-- adrian

On Mar 14, 2014, at 18:39, David Blaikie <dblaikie at gmail.com> wrote:

> 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