[LLVMdev] First-class debug info IR: MDLocation (original) (raw)

David Blaikie dblaikie at gmail.com
Mon Oct 27 09:33:57 PDT 2014

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/classtype'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>

More information about the llvm-dev mailing list