[LLVMdev] "distinct" metadata nodes are ...?

[David Blaikie]

On Mon, Apr 6, 2015 at 10:26 AM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> I'm encountering a merge issue whose root cause has to do with "distinct"
> metadata nodes.  I see that distinct-ness is an intentional concept, but
> the explanation in the LLVM Language Reference is not very enlightening.
>
>     distinct nodes are useful when nodes shouldn't be merged based on
>     their content.
>
> The notion of "merged" metadata is not discussed elsewhere on the page,
> except for Objective-C garbage collection; I'm looking at debug location
> metadata, so that's not relevant.
>
> I understand that distinct-ness was invented as a replacement for a
> self-reference hack, but that just begs the question. Why is this a
> useful concept?  What is it used for?  Why shouldn't certain nodes be
> merged based on their content?
>
> My specific issue has to do with inlined-at chains.  If I have
>     return inlined_func() + 1;
> the inlined-at chain for inlined_func() [and whatever else is inlined
> into inlined_func()] terminates in a node that is 'distinct' from the
> node for the calling statement, even though they describe the same
> source location.  This didn't used to be a problem, chasing the chain
> ended up with something that compared equal to the calling statement's
> source location.
>

http://llvm.org/viewvc/llvm-project?rev=226736&view=rev is the change that
caused this & has some context on why it's necessary.

The issue is that the scope change of debuglocs is how we build scopes,
including inline scopes (DW_TAG_inlined_subroutine). If the call site
locations aren't uniqued, then two calls from the same line to the same
function would have the same location and thus be the same scope - so we'd
only have one DW_TAG_inlined_subroutine, instead of two.

Clang worked around this for a while by putting column info on call sites
to help give them unique call sites, but this was insufficient (the two
calls could've come from within a macro, in which case they'd be attributed
to the same line/column again).

- David


>
> Thanks,
> --paulr
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150406/d4c4b471/attachment.html>