[LLVMdev] First-class debug info IR: MDLocation

[Chandler Carruth]

I haven't been able to follow all of the thread that got us here but your
patch below has distilled the result enough for me to at least ask
questions.

I'm sorry of some of the justification is buried in the thread and I'm just
making you repeat it, but I suspect I'm not the only one that would benefit
from the rationale being summarized here.

On Fri, Oct 24, 2014 at 4:16 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> Using `Value` instead of `MDNode`
> =================================
>
> A number of APIs expect `MDNode` -- previously, the only referenceable
> type of metadata -- but this patch (and the ones that will follow) have
> referenceable metadata that *do not* inherit from `MDNode`.  Metadata
> APIs such as `Instruction::getMetadata()` and
> `NamedMDNode::getOperand()` need to return non-`MDNode` metadata.
>

To me, this change is a red flag and points out a bit of a lie in the
subject line: this is not actually first-class debug-info IR. This is just
making debug info become special metadata with special encoding properties.

Note, I'm actually ok with us having special metadata that has special
encoding properties. But if we're going that route, I don't think that
there is anything "debug info" centric about it, and it shouldn't be
described as such. I also think the relationship of MDUser, MDNode, and
MDString need to be clarified a great deal. Why doesn't getMetadata return
an 'MDUser*' for example?

It feels as though you really want to sink the current functionality of
MDNode down to some subclass of a more generic metadata IR type? Maybe I'm
misunderstanding?


I also have to ask because I can't currently see it: what does debug info
being metadata buy us? How much code is simplified by that, and at what
cost?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/d1679aa7/attachment.html>