[PATCH] IR: Add specialized debug info metadata nodes

David Blaikie dblaikie at gmail.com
Wed Feb 4 14:58:04 PST 2015


On Wed, Feb 4, 2015 at 2:50 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> Add specialized debug info metadata nodes that match the `DIDescriptor`
> wrappers (used by `DIBuilder`) closely.  Assembly and bitcode support to
> follow soon (it'll mostly just be obvious), but this sketches in today's
> schema.  This is the first big commit (well, the only *big* one aside
> from the testcase changes that'll come when I move this into place) for
> PR22464.
>
> I've marked a bunch of obvious changes as `TODO`s in the source; I plan
> to make those changes promptly after this hierarchy is moved underneath
> `DIDescriptor`, but for now I'm aiming mostly to match the status quo.
>
> I don't need a low-level review here (although always welcome); I'm
> mainly looking for the following:
>
>   - The word 'context' is overloaded: `MDNode::getContext()` already
>     exists, and returns an `LLVMContext&`; `DIDescriptor` uses 'context'
>     to mean "the node that this one is defined inside".  I chose the
>     word 'parent' instead of 'context' here.  Is this word okay?  If
>     not, what about 'scope'?  This will be reflected in the assembly
>     changes to come (I'd like the C++ names to match the assembly names,
>     although technically it's not necessary).
>

I'd /probably/ go with scope (we already have scope in the MDLocations, so
that seems consistent), but fairly on-the-fence.


>   - Aside from the above, did I fail to match the current schema (in
>     llvm/IR/DebugInfo.h) some other way?
>   - I did this work as one big chunk because it was the easiest way for
>     me to match the hierarchy.  I imagine reviewing it as a whole is
>     easier for the same reason, but if someone has a strong preference
>     for this to be broken up when I commit it (it'd take some work, but
>     it would be mechanical) let me know.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150204/593e2567/attachment.html>


More information about the llvm-commits mailing list