This is the mail archive of the
mailing list for the GCC project.
Re: [ubsan] Use pointer map instead of hash table.
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 28 Aug 2013 15:05:37 +0200
- Subject: Re: [ubsan] Use pointer map instead of hash table.
- Authentication-results: sourceware.org; auth=none
- References: <20130827123338 dot GA574 at redhat dot com> <CAFiYyc1VL-yEAjuhbrPMthnak6u48yN+Rm1LnLRVV18RpXx0PA at mail dot gmail dot com> <20130828121543 dot GD574 at redhat dot com> <CAFiYyc32h_fAZfgkvhfOO-Pr1zzgsYo7A+WCgFAR=gorOVyG4Q at mail dot gmail dot com> <20130828125701 dot GF574 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Aug 28, 2013 at 02:57:01PM +0200, Marek Polacek wrote:
> On Wed, Aug 28, 2013 at 02:49:54PM +0200, Richard Biener wrote:
> > On Wed, Aug 28, 2013 at 2:15 PM, Marek Polacek <firstname.lastname@example.org> wrote:
> > > On Wed, Aug 28, 2013 at 12:40:50PM +0200, Richard Biener wrote:
> > >> On Tue, Aug 27, 2013 at 2:33 PM, Marek Polacek <email@example.com> wrote:
> > >> > It turned out that for tree -> tree mapping we don't need the hash
> > >> > table at all; pointer map is much more convenient. So this patch
> > >> > weeds out the hash table out of ubsan and introduces pointer map
> > >> > instead. Quite a lot of code could go away--no need to set the
> > >> > alloc pools up etc.
> > >> >
> > >> > Regtested, ran bootstrap-ubsan on x86_64-linux. Applying to the
> > >> > ubsan branch.
> > >>
> > >> You can use the type-safe pointer_map <tree> now (ok, only the data type
> > >> is type safe, the pointer is still void).
> > >
> > > Thanks, done with the following. Please let me know if you see
> > > something wrong in this; otherwise I'll commit it if the
> > > bootstrap-ubsan passes.
> > Probably misses freeing of the pointer-map using 'delete' somewhere.
> That's a problem, since ubsan is not a pass, we can't simply delete
> the map at the end of the pass when it's not needed anymore...
> Perhaps some GTY(()) stuff could do it, but I don't know which one.
You basically want to keep the pointer map for as long as you can
lookup types, which is done now from both FEs and
middle-end? I guess it is the same category as say
debug_expr_for_decl or value_expr_for_decl map tables, which we never free
either. But for those we indeed
GTY ((if_marked ("tree_decl_map_marked_p"), param_is (struct tree_decl_map)))
and thus remove items if the original decl is not referenced from anywhere
else; but pointer_map doesn't allow item removal; do we walk it for GC at
all? If so, it might prevent some types from being GC collected, on the
other side right now it isn't expected that too many types will be put into