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

[Peter Collingbourne via llvm-commits]

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.

> (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.

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