[PATCH] Do not split variables definitions into 2 DIEs.

Frederic Riss friss at apple.com
Tue Sep 23 10:06:16 PDT 2014


================
Comment at: test/DebugInfo/X86/gnu-public-names.ll:56
@@ -56,2 +55,3 @@
+; CHECK: [[STATIC_MEM_VAR:0x[0-9a-f]+]]: DW_TAG_member
 ; CHECK-NEXT: DW_AT_name {{.*}} "static_member_variable"
 
----------------
dblaikie wrote:
> This actually seems like it /might/ be a reasonable place for a separate declaration and definition, since the user wrote an out of line definition.
> 
> What location do we attribute the definition to? It might be worth checking the decl_line attribute in this test. Did we previously attribute the declaration and definition to their respective lines, or just duplicate one/the other of them?
> 
> How does this compare to other nested definitions (I suppose for functions in namespaces we don't emit both distinguishing the declaration and definition in cases like: "namespace x { void func(); } void x::func() {}" so there's arguably no reason to similarly for variables)
I would agree totally if we somehow emitted information corresponding to the definition location in the debug info. But the only line information that we provide is the one of the declaration in all cases (the attribute is called decl_line, so maybe that's really how it should be). If the definition DIE has no overlapping attributes with the declaration, I don't see a reason to keep both.
There is one thing that is special to class members though. If we only emit a definition (what the patch actually does), it will be inside the type. And this is be an issue if we want to emit type units, isn't it? Maybe this whole split-if-not-file/function-scope heuristic is to only ever emit declarations into classes.
For functions in namespaces, we only emit one definition DIE, but for class methods we split declaration and definition. So maybe we should really keep the class type exempt of definitions.

http://reviews.llvm.org/D5457






More information about the llvm-commits mailing list