On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou <ji...@gmx.net> wrote:
> Hello,
>
> 2012-08-19 Dimitrios Apostolou <ji...@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
