[PATCH] Refactor debug info lexical block generation

[Frederic Riss]

REPOSITORY
  rL LLVM

================
Comment at: lib/CodeGen/AsmPrinter/DwarfDebug.cpp:545-549
@@ +544,7 @@
+    bool Skip = Die->getAbbrev().getTag() == dwarf::DW_TAG_lexical_block;
+    for (auto &Child : Die->getChildren()) {
+      Dies.push_back(&*Child);
+      Skip &= (Child->getAbbrev().getTag() == dwarf::DW_TAG_lexical_block ||
+               Child->getAbbrev().getTag() == dwarf::DW_TAG_inlined_subroutine);
+    }
+
----------------
probinson wrote:
> friss wrote:
> > probinson wrote:
> > > aaboud wrote:
> > > > friss wrote:
> > > > > This seems prohibitively expensive, you are adding each and every DIE in the tree to the worklist. I'm pretty sure you could filter to only take subprograms/blocks/inline_subroutines. (Even better, don't we already collect all the functions somewhere?)
> > > > > 
> > > > > This also seems wrong. You might remove inlined_subroutines with that change and we don't want that.
> > > > I will check if I can optimize this loop by traverse only over subprograms/blocks/inline_subroutines.
> > > > 
> > > > However, I do not have a bug here, I will never remove an inline_subroutine.
> > > > I am just collapsing lexical-blocks that does not have any child other than lexical blocks and/or inlined_subroutine.
> > > I don't think this will remove inlined_subroutine DIEs; the intent here is that if a lexical_block contains (only) an inlined_subroutine, it's okay to eliminate the lexical_block, because the inlined_subroutine is its own scope.
> > Doh, you're right. Skip is set only if the current DIE is a lexical block. Still the way this is done seems very expensive. I bet the cost of that walk in noticeable in a RelWithDebugInfo build. Can we get some numbers?
> Maybe DwarfCompileUnit should keep track of the lexical blocks as they get created?  then you can just run that list here.
Is there no way to handle that before generating the DIEs? creating the objects just to destroy them later seems a bit silly (and it's a plain leak once we allocate the DIEs on a BumpPtrAllocator). If the variable itself needs to be in the globals list, maybe we still can mark it's scope with a special flag that prevents its coalescing?

http://reviews.llvm.org/D9960

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/