[PATCH] D17321: DIEData, DIEWriter: introduce and begin migration.

[David Blaikie via llvm-commits]

On Wed, Feb 17, 2016 at 4:02 PM, Peter Collingbourne via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> pcc added a comment.
>
> > The odd/even abbrev numbering seems a bit awkward - can we just build
> the new infrastructure closer to the old stuff, so they can pick numbers
> more closely?
>
>
> Maybe, but I'd like to avoid having the new code and the old code interact
> where possible. In particular, I think the code would be a little harder to
> unit test if I use the old code for abbreviations.
>

Fair - perhaps they could still share a counter, though, somehow. But maybe
not worth it. I wonder how novel out of order abbreviations are... (whether
it'll trip up any consumers)


>
> > (have you done any size analysis of this change - I realize the
> numbering of DIEs is probably a small component of DWARF size, but this
> change sounds like it'd increase DWARF size a little?)
>
>
> I'll see what the impact is on Chromium.
>
> > The abbreviation won't be known until the end of DWARF emission
>
>
> Is this true? Since the abbreviation depends only on the attribute names
> and forms, I suspect that in many cases we can compute an abbreviation up
> front and fill in attribute values later.
>
> For example, the abstract origins for concrete variables added by
> `DwarfDebug::finishVariableDefinitions`. Since we know at `DbgVariable`
> creation time whether a variable is concrete or not, we can create an
> abstract origin attribute with some arbitrary value for concrete variables
> when we create them (in the equivalent of
> `DwarfCompileUnit::constructVariableDIEImpl`), store a reference to that
> attribute somewhere (which could just be a `DIEData`+offset pair), and use
> that in `DwarfDebug::finishVariableDefinitions` to fill in the value.
>

It's not quite that simple - the reason finishVariableDefinitions (& other
similar things - this applies to subprograms, local variables, and some
local scopes) happens at the end is that we don't know at the time we see
the concrete definition whether we will see inline definitions as well.

Essentially the DWARF looks like:

  subprogram
    name
    ...
    high_pc
    low_pc

if there's no inlining, but if there is inlining it looks like:

  X: subprogram
    name
    ...

  subprogram
    abstract_origin X
    high_pc
    low_pc
    ...

  ...
  inline_subroutine
    abstract_origin X
    high_pc
    low_pc
    ...

This is the only attribute case I know of (inlining - subprograms,
variables, and local scopes)- there are many cases where we don't know all
the children up-front. (implicit special members, nested types, local
scopes, any namespaces)

What did you have in mind for unbounded children? keeping an insertion
point into the DWARF byte buffer & moving things out of the way to make
room for the missing children?


>
> If there are cases where we truly cannot know about the existence of an
> attribute until later, then we can probably try something like maintaining
> a flag which would only be relevant for those DIE tags which can have
> attributes inserted dynamically, and have the code in
> `DIEData::{prepareToEmit,emit}` create abbreviations on demand for those
> specific tags, but I'd like to try to find a way to avoid that if possible.
>
>
> http://reviews.llvm.org/D17321
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160218/a408174b/attachment.html>