llvm dev - Oct 2014 - [LLVMdev] First-class debug info IR: MDLocation

> 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?

Also, would there be value in modelling type units more explicitly in
the IR?
> 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 guess we'll
sort that out when I get there.
> 
> 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.

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>

> On 2014-Oct-27, at 09:33, David Blaikie <dblaikie at gmail.com>
wrote:
> 
>> > 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 don't know :).

@Adrian?
>> I guess we'll sort that out when I get there.
> 
> Sure enough.