[llvm] r225401 - IR: Add MDNode::isDistinct()

[Duncan P. N. Exon Smith]

> On 2015-Jan-12, at 13:17, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Mon, Jan 12, 2015 at 1:09 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 
> > On 2015-Jan-12, at 12:59, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Mon, Jan 12, 2015 at 11:16 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> >
> > > On 2015-Jan-12, at 11:07, David Blaikie <dblaikie at gmail.com> wrote:
> > >
> > >
> > >
> > > On Wed, Jan 7, 2015 at 1:35 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> > > Author: dexonsmith
> > > Date: Wed Jan  7 15:35:38 2015
> > > New Revision: 225401
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=225401&view=rev
> > > Log:
> > > IR: Add MDNode::isDistinct()
> > >
> > > Add API to indicate whether an `MDNode` is distinct.  A distinct node is
> > > not stored in the MDNode uniquing tables, and will never be returned by
> > > `MDNode::get()`.
> > >
> > > Although distinct nodes are only currently created by uniquing
> > > collisions (when operands change),
> > >
> > > I don't quite understand how changing an operand relates to uniquing collisions - once the operand has changed would we not want the uniquing to happen again? (eg: if changing an operand made this node equal to some other node instead?)
> > >
> >
> > It's impossible without RAUW.
> >
> > Even when doing that, it seems strange that it would prevent uniquing - but again, I guess I'm missing something.
> >
> > I would sort of expect:
> >
> > {1, 2}
> > 1 = {a}
> > 2 = {b}
> >
> > RAUW a -> b
> >
> > {2, 2}
> > 2 = {b}
> >
> > it sort of seems strange
> 
> It is strange :/.
> 
> >  to me that the path (directly constructing, versus constructing then RAUWing) to create the value produces a different graph/node/etc?
> >
> > - David
> 
> It's unavoidable though.  Concrete example:
> 
>     @g1 = global i32 0
>     @g2 = global i32 0
> 
>     !0 = !{i32* @g1}
>     !1 = !{i32* @g2}
>     !2 = !{!0, !1}
> 
> `@g1->replaceAllUsesWith(@g2)` calls `!0->handleChangedOperand(0, @g2)`.
> 
> In there, we call `MDNode::getIfExists(Context, @g2)` and get back `!1`.
> This is a uniquing collision.
> 
> `!0` isn't tracking its users,
> 
> Would this have been true back before the metadata/value split - is this a change in behavior since then?

This was the fundamental change in behaviour we got from the split:
stop paying for the RAUW machinery, but lose the ability to RAUW.

Uniquing was dropped before the split already, when operands went
to null (or true-Value operands were deleted via `Value::IsDeleted()`).

>  (I assume not, because I imagine that would break things)

Nothing seems to have broken, actually :).

> Values no their uses, right?

Right.

> (but not their metadata uses, even before the metadata/value split?)

Right, this hasn't changed.  Although they metadata was updated anyway
via `CallbackVH`.

>  
> so it doesn't know about `!2`.  We'd really
> like to call `!0->replaceAllUsesWith(!1)`, but we can't.
> 
> Instead, we're left with this:
> 
>     @g1 = global i32 0
>     @g2 = global i32 0
> 
>     !0 = distinct !{i32* @g2}
>     !1 = !{i32* @g2}
>     !2 = !{!0, !1}