<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 17, 2016 at 4:02 PM, Peter Collingbourne via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">pcc added a comment.<br>
<span class=""><br>
> 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?<br>
<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> (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?)<br>
<br>
<br>
</span>I'll see what the impact is on Chromium.<br>
<span class=""><br>
> The abbreviation won't be known until the end of DWARF emission<br>
<br>
<br>
</span>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.<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br><br>Essentially the DWARF looks like:<br><br>  subprogram<br>    name<br>    ...<br>    high_pc<br>    low_pc<br><br>if there's no inlining, but if there is inlining it looks like:<br><br>  X: subprogram<br>    name<br>    ...<br><br>  subprogram<br>    abstract_origin X<br>    high_pc<br>    low_pc</div><div>    ...</div><div><br>  ...<br>  inline_subroutine<br>    abstract_origin X<br>    high_pc<br>    low_pc<br>    ...<br>    </div><div>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)<br><br>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D17321" rel="noreferrer" target="_blank">http://reviews.llvm.org/D17321</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>