Re: Summary of patches

[Jan Hubicka <hubicka at ucw dot cz>]

> Jan Hubicka <jh@suse.cz> writes:
> >   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02550.html
> >     - loglinks in allocpools
> 
> Is INSN_UID reset between functions?  If not, that array is going to
> get huge and I don't think this is a good idea.
It is reset for each function and additionally we we do have
renumber_insns that renumber them for large functions.  The array field
was originally present in each insn container anyway, so without garbage
collection we get exactly the same memory overhead.

This patch is mostly just a first step - in general I would preffer the
log links moved completely out of RTL land and use their own
datastrcture, but things are quite interwinded so it it is dificult to
do at one step.
> 
> >   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01979.html
> >     - Varrays allocated by xmalloc
> 
> The ggc-none implementation of ggc_free is OK; please commit that
> separately.
> 
> I do not like the part where you change every last instance of
> VARRAY_*_INIT.  I would prefer if there were some automatic way to
> determine whether or not a varray needed to be allocated via
> ggc_alloc.  Better still, figure out some way whereby varrays can be

We do have similar way of choosing allocation strategy for hashtables too.
I don't quite see how this can be done automatically as one never knows
where the pointer to hashtable will be assigned to.

> marked and swept without ever using ggc_alloc (which is not suited to
> resizable data structures) for them.

I will try to think about this deeper, but it seems to be that we will
just end up with two ggc allocators hooked together.  With Richard's
ggc_free patch we can now release the memory explicitely, so I am not
quite sure what is the most sane approach here.
> 
> > Per call statistics:
> >   (there is only one conflict if the patch is applied to tree-ssa branch so it
> >   should not bring any merge problems to Diego)
> >   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02193.html
> 
> This is OK provided that you submit a follow-up patch which adds
> --enable-statistics to configure.

There is already:
--enable-gather-detailed-mem-stats         enable detailed memory allocation stats gathering

Thank you!
Honza