llvm dev - Oct 2013 - [LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication

>
>
> patch looks fairly obvious/trivial
>
> Have you tried any of the test cases I've described (special members,
> nested types, and member templates - all used across CUs so an earlier CU
> has the type definition and a latter one has one of these extra members)?
> I'd like to see test results for these before we progress.
>
Yes, templates and nested types where we have two MDNodes for the same
class, and one has an extra member.
They work fine with the patch (no assertion failure).

Manman
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131016/a576b831/attachment.html>

On Wed, Oct 16, 2013 at 1:33 PM, Manman Ren <manman.ren at gmail.com>
wrote:
>
>> patch looks fairly obvious/trivial
>>
>> Have you tried any of the test cases I've described (special
members,
>> nested types, and member templates - all used across CUs so an earlier
CU
>> has the type definition and a latter one has one of these extra
members)?
>> I'd like to see test results for these before we progress.
>>
>
> Yes, templates and nested types where we have two MDNodes for the same
> class, and one has an extra member.
>
Could you include the tests (or at least in a separate patch if you think
they're so uninteresting as to possibly not be needed with your change)?

I'd be interested to see how you constructed/tested them, which order the
CUs came in, how the mismatch was resolved, etc.

> They work fine with the patch (no assertion failure).
>
I'm interested in more than just the absence of assertions. (or are you
referring to the kind of assertion machinery we've touched on in this
thread but I haven't seen your code for - in which we keep a mapping of
assumptions and verify those assumptions when a DIE is added to its parent
and the assumption is resolved?)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131016/cf34c323/attachment.html>

On Wed, Oct 16, 2013 at 2:00 PM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
>
> On Wed, Oct 16, 2013 at 1:33 PM, Manman Ren <manman.ren at gmail.com>
wrote:
>
>>
>>> patch looks fairly obvious/trivial
>>>
>>> Have you tried any of the test cases I've described (special
members,
>>> nested types, and member templates - all used across CUs so an
earlier CU
>>> has the type definition and a latter one has one of these extra
members)?
>>> I'd like to see test results for these before we progress.
>>>
>>
>> Yes, templates and nested types where we have two MDNodes for the same
>> class, and one has an extra member.
>>
>
> Could you include the tests (or at least in a separate patch if you think
> they're so uninteresting as to possibly not be needed with your
change)?
>
> I'd be interested to see how you constructed/tested them, which order
the
> CUs came in, how the mismatch was resolved, etc.
>
Sure, I can add the testing cases in a separate patch.

>
>
>> They work fine with the patch (no assertion failure).
>>
>
> I'm interested in more than just the absence of assertions. (or are you
> referring to the kind of assertion machinery we've touched on in this
> thread but I haven't seen your code for - in which we keep a mapping of
> assumptions and verify those assumptions when a DIE is added to its parent
> and the assumption is resolved?)
>
I was referring to the assertion that when emitting ref4, the DIE and the
referenced DIE belong to the same CU (i.e. we made the right
decision about the reference form inside addDIEEntry).

Thanks,
Manman

>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131016/ac5377d7/attachment.html>