aboutsummaryrefslogtreecommitdiffstats
path: root/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2013-10-03 20:07:20 +0000
committerDavid Blaikie <dblaikie@gmail.com>2013-10-03 20:07:20 +0000
commite5830c4e2603ab36f08911ff6bb117638ae529c7 (patch)
tree34b9ca548accd70adcdedd36962062f6b54e3ea7 /lib/CodeGen/AsmPrinter/DwarfDebug.cpp
parentcee51c48030f37133ad4004d3e5c14d8ebfc91c4 (diff)
downloadexternal_llvm-e5830c4e2603ab36f08911ff6bb117638ae529c7.zip
external_llvm-e5830c4e2603ab36f08911ff6bb117638ae529c7.tar.gz
external_llvm-e5830c4e2603ab36f08911ff6bb117638ae529c7.tar.bz2
DebugInfo: Avoid redundantly adding child DIEs to parents.
DIE::addChild had a shortcircuit that silently no-op'd when a child was readded to the same parent. This hid some quirky/redundant code in DwarfDebug/CompileUnit. By removing that functionality and replacing it with an assert I was able to find and cleanup those cases, mostly centering around adding members to types in various circumstances. 1) The original oddity I noticed while working on type units (which actually was helping me in the short term, by accident) was the addToContextOwner call in constructTypeDIE. This call was completely bogus (why was it only done for non-virtual types? what relevance does that have at all) and redundant with the more uniform addToContextOwner made in getOrCreateTypeDIE. 2) If a member function definition was visited (createSubprogramDIE), it would attempt to build the member function declaration. The declaration DIE would then be added to its context, but in building the context (the type for which this function is a member) the members of the type would be added to the type automatically, so by the time the context was constructed, the member function was already associated with it. 3) The same as (2) but without the member function being constructed first. Whenever a type was constructed, the members would be created and member functions would be created by getOrCreateSubprogramDIE - this would lead to the subprogram being added to the (incomplete) type already, then the general member-construction code would add it again. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191928 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/CodeGen/AsmPrinter/DwarfDebug.cpp')
-rw-r--r--lib/CodeGen/AsmPrinter/DwarfDebug.cpp6
1 files changed, 0 insertions, 6 deletions
diff --git a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
index 1e08e2c..557ae1d 100644
--- a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
+++ b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
@@ -838,12 +838,6 @@ void DwarfDebug::constructSubprogramDIE(CompileUnit *TheCU,
DIE *SubprogramDie = TheCU->getOrCreateSubprogramDIE(SP);
- // Add to map.
- TheCU->insertDIE(N, SubprogramDie);
-
- // Add to context owner.
- TheCU->addToContextOwner(SubprogramDie, SP.getContext());
-
// Expose as a global name.
TheCU->addGlobalName(SP.getName(), SubprogramDie);
}