[LLVMdev] Questions before moving the new debug info hierarchy into place

[Duncan P. N. Exon Smith]

I'm getting close to executing the transition to the new debug info
hierarchy.  For reference, I've attached two WIP patches (which would be
squashed before commit) and the WIP upgrade script I'm using.

    - transition-code.patch: Change the `DIDescriptor` hierarchy to
      lightweight wrappers around the subclasses of `DebugNode` (instead
      of rather heavier wrappers around `MDTuple`), and update
      `DIBuilder` to generate the right things.
    - transition-testcases.patch: Upgrade of testcases, entirely
      generated from the upgrade script (so far).
    - upgrade-specialized-nodes.sh: Script to upgrade LLVM assembly.

(Feel free to have a look, but I haven't updated LangRef, I don't quite
have `make check` passing, and I haven't even started on `make
check-clang` (I imagine that'll all be done by hand).)

There are two outstanding issues I'd like some feedback on.

Pretty-printing the flags
=========================

I've noticed the `flags:` field is *harder* to read in the new assembly:

    !MDDerivedType(flags: 16384, ...)

than the pretty-printed comments in the old:

    !{!"...\\0016384", ...} ; ... [public] [rvalue reference]

I don't want to regress here.

In `DIDescriptor`, the flags are described in an enum bitfield:

    FlagAccessibility     = 1 << 0 | 1 << 1,
    FlagPrivate           = 1,
    FlagProtected         = 2,
    FlagPublic            = 3,
    FlagFwdDecl           = 1 << 2,
    FlagAppleBlock        = 1 << 3,
    FlagBlockByrefStruct  = 1 << 4,
    FlagVirtual           = 1 << 5,
    FlagArtificial        = 1 << 6,
    FlagExplicit          = 1 << 7,
    FlagPrototyped        = 1 << 8,
    FlagObjcClassComplete = 1 << 9,
    FlagObjectPointer     = 1 << 10,
    FlagVector            = 1 << 11,
    FlagStaticMember      = 1 << 12,
    FlagLValueReference   = 1 << 13,
    FlagRValueReference   = 1 << 14

I think the right short-term solution is to use these names directly in
assembly, giving us:

    !MDDerivedType(flags: FlagPublic | FlagRValueReference, ...)

This is easy to implement and easy to CHECK against.

Sound good?

(Eventually, I'd like to use the `DW_AT` symbols that each of these
corresponds to, but `FlagStaticMember` doesn't seem to line up with any
such `DW_AT` so that will take some refactoring (and I don't think it
makes sense for that to block moving the hierarchy into place).)

Merging the two types of files
==============================

In the old format, we have two types of files -- an untagged file node,
and a DIFile/DW_TAG_file_type/0x29 which references the untagged node.

    !0 = !{!"path/to/file", !"/path/to/dir"}
    !1 = !{!"0x29", !0}

In the actual metadata graph, most file references use !0, but in
DIBuilder !1 is always passed in and the !0 is extracted from it.

I've been planning to merge these into:

    !1 = !MDFile(filename: "path/to/file", directory: "/path/to/dir")

Anyone see a problem with that?  Why?

If not, I'd like to roll that change into the same patch in order to
reduce testcase churn.  (I've discovered that it won't complicate the
code patch at all.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: transition-code.patch
Type: application/octet-stream
Size: 325 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/57938fb3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transition-testcases.patch
Type: application/octet-stream
Size: 1754066 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/57938fb3/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: upgrade-specialized-nodes.sh
Type: application/octet-stream
Size: 49628 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150219/57938fb3/attachment-0002.obj>
-------------- next part --------------