Hi Steven,
On Sun, 19 Aug 2012, Steven Bosscher wrote:
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).
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
