[LLVMdev] First-class debug info IR: MDLocation

[David Blaikie]

On Mon, Oct 27, 2014 at 9:22 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On 2014-Oct-24, at 16:37, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >> Notice that only the links to parents (i.e., `context:`) are explicit
> >> here -- backlinks are implied.  For example, !7 and !8 point to !6, but
> >> not the reverse.
> >
> > This may be a problem - the difference between nodes in a
> structure/class_type's member list, and those that are not in the member
> list but refer to the class/structure as their parent is meaningful. Type
> units use this distinction to avoid emitting instantiation-specific data
> into the canonical type unit (nested classes, implicit special members,
> member template instantiations, etc).
> >
> > Not sure what the right answer will be there.
>
> Interesting.  Could we model that with a Boolean flag on the child?
>

That would be an option.


> Also, would there be value in modelling type units more explicitly in
> the IR?
>

I don't see any particular value there, given the type uniquing work that's
already been done, etc.


> > Presumably when dumping the fields will come in a specific, defined
> order? (probably not preserving the original source order, etc) Variation
> there would probably make checking harder than it needs to be.
>
> Right.
>
> >
> > Would it be possible to omit the names of unreferenced nested metadata?
> (if you have a bunch of member functions in a class, but don't need to
> refer to them elsewhere (eg: those member functions aren't defined in this
> translation unit)) - that'd help readability/writeability, but probably
> wouldn't impact FileCheck.
>
> Certainly possible, but is it generally desirable?


I would imagine so - is there any reason the names/numbers would be
preferable?


>   I guess we'll
> sort that out when I get there.
>

Sure enough.


>
> >
> > Also the whole "metadata " prefix on anything is a bit verbose, if we
> can omit that in some/many places, that'll help reduce the visual
> noise/improve readability/writeability.
> >
> > But most/all of that I imagine is fairly easily incremental
> change/improvement, nothing fundamental that needs to be chosen up-front.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/edfa149b/attachment.html>