Duncan P. N. Exon Smith
2014-Oct-27 16:22 UTC
[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>
Duncan P. N. Exon Smith
2014-Oct-27 18:18 UTC
[LLVMdev] First-class debug info IR: MDLocation
> 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.