Re: ping again - Show hash table stats when -fmem-report

[Dimitrios Apostolou <jimis at gmx dot net>]

I'm always forgetting something, now it was the changelog, see attached 
(same as old, nothing significant changed).

On Fri, 3 Aug 2012, Dimitrios Apostolou wrote:

> Hi, I've updated this patch to trunk and rebootstrapped it, so I'm 
> resubmitting it, I'm also making a try to CC all relevant maintainers, sorry 
> for spamming but even though this patch is simple, it touches many parts.
>
> I'm also adding stats to pointer_{set,map} but it will come in a separate 
> patch. The notes quoted from earlier mail still apply:
>
> On Sun, 8 Jul 2012, Dimitrios Apostolou wrote:
>
> > Hi,
> >
> > This patch adds many nice stats about hash tables when gcc is run with 
> > -fmem-report. Attached patch tested on x86, no regressions.
> >
> > Also attached is sample output of -fmem-report when compiling reload.c with 
> > -O2 -g. Especially interesting is the extreme htab usage in var-tracking 
> > (ofcourse we already knew that... :-) and maybe symtab's slightly high 
> > collision rate (given it's a very hot hash table). Moreover it's notable 
> > that since last year, collision rate for mem_attrs_htab has been reduced 
> > from around 8 to 1, still not good enough but major improvement.
> >
> > Jan: It has negligible overhead in runtime, that's why I'm pushing it again 
> > as it is. Having compile-time instrumentation is something different, but 
> > still I'm not quite sure if it's worth the effort. IMHO doing separate 
> > builds to get memory info is tedious and even I've stopped doing them. If 
> > it has no overhead maybe it's better as a runtime option?
> > Any way, compile-time instrumentation can come later.
> >
> > Finally I repost some of my notes I'd like to get feedback on:
> >
> > * Is it OK that I included <assert.h> in libiberty's hashtab.c? What's the 
> > proper way to assert stuff, since gcc_assert() is not accessible?
> >
> > * Many hash tables are created with htab_create_ggc(), for example 
> > referenced_vars and default_defs in tree-ssa.c. I collect statistics in 
> > delete_tree_ssa() but maybe some are not deallocated in there but 
> > automatically garbage collected?
> >
> > * Obviously hash table sizes are inflated where two entries might reference 
> > the same element (for example in symtab_hash) but I don't handle this.
> >
> > * Changes that reduce load factor have been backed out since they brought 
> > controversy. I still think they are good, at least for symtab. I'll measure 
> > numbers separately for this after this patch makes it.
> >
> >
> > Thanks,
> > Dimitris

Attachment: Changelog.df-3
Description: Text document