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).