search for: dw_tag_imported_module

..., metadata [[M5:![0-9]*]], metadata [[M6:![0-9]*]], metadata [[M7:![0-9]*]], metadata [[M8:![0-9]*]], metadata [[M9:![0-9]*]], metadata [[M10:![0-9]*]], metadata [[M11:![0-9]*]], metadata [[M12:![0-9]*]]} // CHECK: [[M1]] = metadata !{i32 {{[0-9]*}}, metadata [[CTXT]], metadata [[NS]], i32 11} ; [ DW_TAG_imported_module ] -// CHECK: [[M2]] = metadata !{i32 {{[0-9]*}}, metadata [[CU]], metadata [[CTXT]], i32 {{[0-9]*}}} ; [ DW_TAG_imported_module ] -// CHECK: [[M3]] = metadata !{i32 {{[0-9]*}}, metadata [[CU]], metadata [[CTXT]], i32 15, metadata !"E"} ; [ DW_TAG_imported_module ] +// CHECK: [[M2]] = meta...

...l block (DW_TAG_lexical_block) entry. Each entity will have a dwarf entry placed under the lexical block scope the same as appear in the source. (1) DW_TAG_subprogram (concrete) DW_AT_name (= "foo") DW_AT_low_pc DW_AT_low_high (2) LexicalBlock DW_AT_low_pc DW_AT_low_high (3) DW_TAG_imported_module DW_AT_import (=> N) (3) DW_TAG_imported_declaration DW_AT_import (=> N::D) (3) DW_TAG_typedef DW_AT_name (= "A") DW_AT_type (=> int) (3) DW_TAG_class_type DW_AT_name (= "B") (4) DW_TAG_variable DW_AT_name (= "x") DW_AT_type (= int) (3)...

.... other stuff namespace MYSPACE { typedef long MYLONG; }; then Clang will emit two separate DW_TAG_namespace DIEs, one with a child MYINT and one with a child MYLONG. However, these namespace DIEs are not connected by DW_AT_extension, so a "using namespace MYSPACE;" that emits a single DW_TAG_imported_module isn't going to catch both namespace DIEs. I looked at gcc, and an EDG-based compiler; they collect all the declarations for a given namespace and put them out under a single DW_TAG_namespace DIE, regardless of how many fragments there are in the source. That way, one DW_TAG_imported_module wil...

...al block scope the same as appear in the source. > > > > (1) DW_TAG_subprogram (concrete) > > DW_AT_name (= "foo") > > DW_AT_low_pc > > DW_AT_low_high > > > > (2) LexicalBlock > > DW_AT_low_pc > > DW_AT_low_high > > > > (3) DW_TAG_imported_module > > DW_AT_import (=> N) > > > > (3) DW_TAG_imported_declaration > > DW_AT_import (=> N::D) > > > > (3) DW_TAG_typedef > > DW_AT_name (= "A") > > DW_AT_type (=> int) > > > > (3) DW_TAG_class_type > > DW_AT_name (=...

...ation_type Tag = 11, Count = 360390, Ops = 1081170, Name = DW_TAG_lexical_block Tag = 258, Count = 1, Ops = 1, Name = DW_TAG_expression Tag = 13, Count = 73880, Ops = 299110, Name = DW_TAG_member Tag = 58, Count = 1387, Ops = 4161, Name = DW_TAG_imported_module Tag = 1, Count = 2747, Ops = 21976, Name = DW_TAG_array_type Tag = 46, Count = 1341021, Ops = 12069189, Name = DW_TAG_subprogram Tag = 257, Count = 4373879, Ops = 20785065, Name = DW_TAG_arg_variable Tag = 8, Count = 2246, Ops = 6738, Name = DW_TAG_...

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan,