[llvm-dev] [DebugInfo] Enabling constructor homing by default
Jeremy Morse via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 17 11:20:10 PST 2020
Hi debug-info folks,
I've recently been experimenting with the -debug-info-kind=constructor
model for debug-info creation, which is leading to some significant
reductions in .debug_info on our large C++ benchmarks, which is great!
I see in PR46537 that there's a plan to eventually enable this by
default -- is this something we can target for LLVM12, or are there
outstanding issues?
While experimenting I was also interested to see that for DWARF and
constructor homing, we emit skeleton type definitions if functions
have an inlined copy in the translation unit. For example in [0] where
I've uploaded a couple of dexter tests for constructor homing, in
partial-type/main.cpp we get:
DW_TAG_class_type
DW_AT_name ("foo")
DW_AT_declaration (true)
DW_TAG_subprogram
DW_AT_linkage_name ("_ZNK3foo8asStringB5cxx11Ev")
DW_AT_name ("asString")
DW_AT_decl_file ("./theclass.h")
DW_AT_decl_line (12)
DW_AT_type (0x000014e6 "string")
DW_AT_declaration (true)
DW_AT_external (true)
DW_AT_accessibility (DW_ACCESS_public)
DW_TAG_formal_parameter
DW_AT_type (0x0000371b "const foo*")
DW_AT_artificial (true)
NULL
And as expected no further type information (aside from the
destructor, also inlined). It seems gdb and lldb are able to find the
full type definition even when there's a skeleton type. When exploring
this with Paul, we worried a bit that LTO could de-duplicate to the
skeleton type definition rather than the full one, is there protection
against that happening somewhere?
[0] https://reviews.llvm.org/D91648
--
Thanks,
Jeremy
More information about the llvm-dev
mailing list