This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] free_lang_data fixes (PR lto/89692)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 21 Mar 2019 09:45:00 +0100
- Subject: Re: [PATCH] free_lang_data fixes (PR lto/89692)
- References: <20190320230204.GQ7611@tucnak> <alpine.LSU.2.20.1903210931090.4934@zhemvz.fhfr.qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Mar 21, 2019 at 09:35:07AM +0100, Richard Biener wrote:
> LGTM - any reason you only sometimes conditionalize add_tree_to_fld_list
> on the fld->pset.add () result? IMHO consistency should win over
> micro-optimizing the case you know the type will not be in the set.
Yeah, it was a optimization for the most common case, when
find_decls_types_r calls add_tree_to_fld_list (t, fld); for DECL_P as well
as TYPE_P, because in that case the fld->pset.add check has been done
already by walk_tree. If we have hundreds thousands of elts in the
hash_set, it could be more than a microoptimization, but if you think
strongly that it should be all thrown away and add_tree_to_fld_list should
start with if (fld->pset.add (t)) return; then I can do that too.
> > 2019-03-20 Jan Hubicka <hubicka@ucw.cz>
> > Jakub Jelinek <jakub@redhat.com>
> >
> > PR lto/89692
> > * tree.c (fld_type_variant): Call fld->pset.add.
> > (fld_incomplete_type_of): Likewise and don't call add_tree_to_fld_list
> > if it returns true.
> > (fld_process_array_type): Likewise.
> > (free_lang_data_in_type): Purge non-marked types from TYPE_NEXT_VARIANT
> > list.
> > (find_decls_types_r): Call fld_worklist_push for TYPE_CANONICAL (t).
> >
> > * g++.dg/other/pr89692.C: New test.
Jakub