Patchwork enlarge hot allocation pools

login
register
mail settings
Submitter Dimitrios Apostolou
Date Aug. 19, 2012, 6:31 p.m.
Message ID <alpine.LNX.2.02.1208191206500.20463@localhost.localdomain>
Download mbox | patch
Permalink /patch/178581/
State New
Headers show

Comments

Dimitrios Apostolou - Aug. 19, 2012, 6:31 p.m.
Hello,

2012-08-19  Dimitrios Apostolou  <jimis@gmx.net>

 	* gcc/cselib.c (cselib_init): Make allocation pools larger since
 	they are too hot and show to expand often on the profiler.
 	* gcc/df-problems.c (df_chain_alloc): Same.
 	* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
 	* gcc/tree-ssa-pre.c (init_pre): Same


These allocation pools are the ones that I've noticed calling malloc() too 
often, for expanding their size. Also I don't like the way the pools are 
created in et_new_{occ,tree}() but couldn't find a single point to move 
the initialisation either. Any ideas on this one?


Thanks,
Dimitris
2012-08-19  Dimitrios Apostolou  <jimis@gmx.net>

	* gcc/cselib.c (cselib_init): Make allocation pools larger since
	they are too hot and show to expand often on the profiler.
	* gcc/df-problems.c (df_chain_alloc): Same.
	* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
	* gcc/tree-ssa-pre.c (init_pre): Same
Steven Bosscher - Aug. 19, 2012, 9:54 p.m.
On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
> Hello,
>
> 2012-08-19  Dimitrios Apostolou  <jimis@gmx.net>
>
>         * gcc/cselib.c (cselib_init): Make allocation pools larger since
>         they are too hot and show to expand often on the profiler.
>         * gcc/df-problems.c (df_chain_alloc): Same.
>         * gcc/et-forest.c (et_new_occ, et_new_tree): Same.
>         * gcc/tree-ssa-pre.c (init_pre): Same
>
>
> These allocation pools are the ones that I've noticed calling malloc() too
> often, for expanding their size.

I don't like the way these pools are sized with a seemingly arbitrary
initial size. They're there to hold something, and they grow because
there are "more somethings" than initially guessed. I think you should
look at what the pools hold and choose an initial size based on some
representative measure. E.g. if a pool holds some kind of expressions,
then you should be able to make an initial guess of the size of the
pool based on the number of pseudos or ssa names. Ideally you'd simply
"derive" the initial pool size by a regression analysis of the final
pool size and some potential representative measures (# of regs, basic
blocks, edges, whatever).


> Also I don't like the way the pools are
> created in et_new_{occ,tree}() but couldn't find a single point to move the
> initialisation either. Any ideas on this one?

Just create a new function to initialize (destroy) the pools and call
it from calculate_dominance_info (free_dominance_info).

Ciao!
Steven
Dimitrios Apostolou - Aug. 20, 2012, 3:25 a.m.
Hi Steven,

On Sun, 19 Aug 2012, Steven Bosscher wrote:
> On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
>> Hello,
>>
>> 2012-08-19  Dimitrios Apostolou  <jimis@gmx.net>
>>
>>         * gcc/cselib.c (cselib_init): Make allocation pools larger since
>>         they are too hot and show to expand often on the profiler.
>>         * gcc/df-problems.c (df_chain_alloc): Same.
>>         * gcc/et-forest.c (et_new_occ, et_new_tree): Same.
>>         * gcc/tree-ssa-pre.c (init_pre): Same
>>
>>
>> These allocation pools are the ones that I've noticed calling malloc() too
>> often, for expanding their size.
>
> I don't like the way these pools are sized with a seemingly arbitrary
> initial size. They're there to hold something, and they grow because
> there are "more somethings" than initially guessed. I think you should
> look at what the pools hold and choose an initial size based on some
> representative measure. E.g. if a pool holds some kind of expressions,
> then you should be able to make an initial guess of the size of the
> pool based on the number of pseudos or ssa names. Ideally you'd simply
> "derive" the initial pool size by a regression analysis of the final
> pool size and some potential representative measures (# of regs, basic
> blocks, edges, whatever).

Some time ago I tried changing the pool allocator growth strategy from 
linear to exponential, doubling the size of the pool chunk every time it 
needed another chunk. It was for the exact same reason, to set the pool 
size according to their contents. Unfortunately I remember it didn't make 
a difference so I dumped it and only manually changed the important pools, 
which made a small difference. I'll now try deducing information on the 
size at runtime, thanks for the tip.


Dimitris

Patch

=== modified file 'gcc/cselib.c'
--- gcc/cselib.c	2012-08-02 22:39:57 +0000

+++ gcc/cselib.c	2012-08-19 15:13:28 +0000

@@ -2659,12 +2659,12 @@  void

 cselib_init (int record_what)
 {
   elt_list_pool = create_alloc_pool ("elt_list",
-				     sizeof (struct elt_list), 10);

+				     sizeof (struct elt_list), 128);

   elt_loc_list_pool = create_alloc_pool ("elt_loc_list",
-				         sizeof (struct elt_loc_list), 10);

+				         sizeof (struct elt_loc_list), 128);

   cselib_val_pool = create_alloc_pool ("cselib_val_list",
-				       sizeof (cselib_val), 10);

-  value_pool = create_alloc_pool ("value", RTX_CODE_SIZE (VALUE), 100);

+				       sizeof (cselib_val), 128);

+  value_pool = create_alloc_pool ("value", RTX_CODE_SIZE (VALUE), 128);

   cselib_record_memory = record_what & CSELIB_RECORD_MEMORY;
   cselib_preserve_constants = record_what & CSELIB_PRESERVE_CONSTANTS;
   cselib_any_perm_equivs = false;

=== modified file 'gcc/df-problems.c'
--- gcc/df-problems.c	2012-08-17 09:42:06 +0000

+++ gcc/df-problems.c	2012-08-19 15:29:37 +0000

@@ -1993,7 +1993,7 @@  df_chain_alloc (bitmap all_blocks ATTRIB

 {
   df_chain_remove_problem ();
   df_chain->block_pool = create_alloc_pool ("df_chain_block pool",
-					 sizeof (struct df_link), 50);

+					 sizeof (struct df_link), 128);

   df_chain->optional_p = true;
 }
 

=== modified file 'gcc/et-forest.c'
--- gcc/et-forest.c	2012-05-31 16:43:31 +0000

+++ gcc/et-forest.c	2012-08-19 15:50:25 +0000

@@ -444,8 +444,8 @@  et_new_occ (struct et_node *node)

 {
   struct et_occ *nw;
 
-  if (!et_occurrences)

-    et_occurrences = create_alloc_pool ("et_occ pool", sizeof (struct et_occ), 300);

+  if (!et_occurrences)

+    et_occurrences = create_alloc_pool ("et_occ pool", sizeof (struct et_occ), 1024);

   nw = (struct et_occ *) pool_alloc (et_occurrences);
 
   nw->of = node;
@@ -467,8 +467,8 @@  et_new_tree (void *data)

 {
   struct et_node *nw;
 
-  if (!et_nodes)

-    et_nodes = create_alloc_pool ("et_node pool", sizeof (struct et_node), 300);

+  if (!et_nodes)

+    et_nodes = create_alloc_pool ("et_node pool", sizeof (struct et_node), 512);

   nw = (struct et_node *) pool_alloc (et_nodes);
 
   nw->data = data;

=== modified file 'gcc/tree-ssa-pre.c'
--- gcc/tree-ssa-pre.c	2012-08-18 06:31:26 +0000

+++ gcc/tree-ssa-pre.c	2012-08-19 15:28:21 +0000

@@ -4812,9 +4812,9 @@  init_pre (bool do_fre)

   phi_translate_table.create (5110);
   expression_to_id.create (num_ssa_names * 3);
   bitmap_set_pool = create_alloc_pool ("Bitmap sets",
-				       sizeof (struct bitmap_set), 30);

+				       sizeof (struct bitmap_set), 128);

   pre_expr_pool = create_alloc_pool ("pre_expr nodes",
-				     sizeof (struct pre_expr_d), 30);

+				     sizeof (struct pre_expr_d), 32);

   FOR_ALL_BB (bb)
     {
       EXP_GEN (bb) = bitmap_set_new ();