Hi, as every year, I went through reasons why types of same ODR name are not merged in firefox streaming. Here are few problems I caught. Remaining issues I understand are 1) odr violations (which is OK of course) 2) keyed vtables: sometimes the vtable decl is weak and sometimes it is external (I have WIP patch for ipa-devirt to stream BINFO_VTABLE off the main stream, but at least for Firefox it does not have any dramatic effects on the size of stream) 3) differences in attribute list (some attributes, like aligned does not make sense on incomplete types, but our FEs lets us to add them there so I think there is no canonical incomplete variant here) 4) TYPELESS storage differences 5) if type is not merged also all types referring to it via TYPE_CONTEXT are not. This still causes propagation from type to another
There are still some cases which I did not track down, but we have only couple hundred of unmerged types, so situation seems to be mostly under control. There is about 700MB of trees in global stream for Firefox + 200MB of in_decl_state vectors and I am not sure if there are easy ways to cut it down. Kind Nodes Bytes ---------------------------------------- constructors 12k 308k vecs 15k 1593k refs 55k 2702k binfos 63k 6670k constants 253k 9760k random kinds 654k 25M exprs 744k 23M identifiers 1217k 47M decls 1583k 293M types 1822k 298M ---------------------------------------- Total 6423k 709M ---------------------------------------- union_type 4335 real_cst 7244 mem_ref 8429 array_type 10k enumeral_type 10k constructor 12k tree_vec 15k array_ref 15k nop_expr 19k component_ref 30k pointer_plus_expr 41k tree_binfo 63k var_decl 78k function_type 106k integer_cst 110k reference_type 125k string_cst 132k type_decl 203k record_type 335k field_decl 355k method_type 583k pointer_type 642k tree_list 654k addr_expr 683k function_decl 941k identifier_node 1217k ---------------------------------------- Bootstrapped/regtested x86_64-linux, OK? Honza * tree.c (fld_incomplete_type_of): Clear TYPE_FINAL_P, TYPE_EMPTY_P, ENUM_IS_OPAQUE and ENUM_IS_SCOPED. (free_lang_data_in_binfo): Clear TREE_PUBLIC in BINFO (free_lang_data_in_type): Clear ENUM_IS_OPAQUE and ENUM_IS_SCOPED. Index: tree.c =================================================================== --- tree.c (revision 277796) +++ tree.c (working copy) @@ -5383,9 +5387,15 @@ fld_incomplete_type_of (tree t, class fr TYPE_TYPELESS_STORAGE (copy) = 0; TYPE_FIELDS (copy) = NULL; TYPE_BINFO (copy) = NULL; + TYPE_FINAL_P (copy) = 0; + TYPE_EMPTY_P (copy) = 0; } else - TYPE_VALUES (copy) = NULL; + { + TYPE_VALUES (copy) = NULL; + ENUM_IS_OPAQUE (copy) = 0; + ENUM_IS_SCOPED (copy) = 0; + } /* Build copy of TYPE_DECL in TYPE_NAME if necessary. This is needed for ODR violation warnings to come out right (we @@ -5468,6 +5478,7 @@ free_lang_data_in_binfo (tree binfo) BINFO_INHERITANCE_CHAIN (binfo) = NULL_TREE; BINFO_SUBVTT_INDEX (binfo) = NULL_TREE; BINFO_VPTR_FIELD (binfo) = NULL_TREE; + TREE_PUBLIC (binfo) = 0; FOR_EACH_VEC_ELT (*BINFO_BASE_BINFOS (binfo), i, t) free_lang_data_in_binfo (t); @@ -5569,6 +5580,8 @@ free_lang_data_in_type (tree type, class { if (TREE_CODE (type) == ENUMERAL_TYPE) { + ENUM_IS_OPAQUE (type) = 0; + ENUM_IS_SCOPED (type) = 0; /* Type values are used only for C++ ODR checking. Drop them for all type variants and non-ODR types. For ODR types the data is freed in free_odr_warning_data. */