On Thu, 7 Nov 2019, Jan Hubicka wrote:
> 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?
OK.
Thanks,
Richard.
> 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. */
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
