Free some more stuff in free_lang_data

[Richard Biener]

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 <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)