Free some more stuff in free_lang_data
diff mbox series

Message ID 20191107131004.no4onem6qaw3xe3e@kam.mff.cuni.cz
State New
Headers show
Series
  • Free some more stuff in free_lang_data
Related show

Commit Message

Jan Hubicka Nov. 7, 2019, 1:10 p.m. UTC
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.

Comments

Richard Biener Nov. 8, 2019, 10:09 a.m. UTC | #1
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.  */
>

Patch
diff mbox series

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.  */