[PATCH] Prevent MDNode's RAUW from introducing a reference to a void Value.

[Duncan P. N. Exon Smith]

> On 2014 Oct 17, at 10:08, David Blaikie <dblaikie at gmail.com> wrote:
> 
> I'm floating the idea that the right fix might be to drop the code, yes. We do this will null pointer dereferences and other cases of UB already (& yes, in LTO this means you might get some surprises - it's rather the nature of UB and optimizations).
> 
>> Coming back to the patch in itself, I also don’t see how it could be the wrong thing to do. The TrackingVH in the MDNode is meant to handle the case of the Value going away. RAUWing with a void value is just another case of a vanishing value.
> 
> I don't think it's really the same though, or at least I don't think it's clean that it needs to be the same. It's a pretty weird way for a value to go away & I'd consider not accepting it as a valid way for a value to go away without, possibly, a stronger example of where this is a reasonable way for a value to go away.

I guess you're suggesting that optimizations shouldn't be allowed to
RAUW a non-void instruction to a void one.  Assuming all the IR `Use`s
have been updated, this RAUW seems legitimate -- it's the only way to
update all the ValueHandles to the instruction.

I think you'd need strong justification to remove this feature.