| Message ID | alpine.LNX.2.02.1208191206500.20463@localhost.localdomain |
|---|---|
| State | New |
| Headers | show |
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
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
=== 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 ();
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