This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [02/13] Replace handle_cache_entry with new interface
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 24 Jun 2015 09:16:40 +0100
- Subject: Re: [02/13] Replace handle_cache_entry with new interface
- Authentication-results: sourceware.org; auth=none
- References: <87fv5s2gej dot fsf at e105548-lin dot cambridge dot arm dot com> <877fr42g8r dot fsf at e105548-lin dot cambridge dot arm dot com> <5589C72D dot 7080605 at redhat dot com>
Jeff Law <law@redhat.com> writes:
> On 06/16/2015 02:45 AM, Richard Sandiford wrote:
>> As described in the covering note, this patch replaces handle_cache_entry
>> with a new function keep_cache_entry. It also ensures that elements are
>> deleted using the proper function, so that m_n_deleted is updated.
>>
>> I couldn't tell whether the unusual name of the function
>> ("gt_cleare_cache") is deliberate or not, but I left it be.
> Short-hand for clear_entry or something similar?
Yeah, could be.
>> gcc/ada/
>> * gcc-interface/decl.c (value_annotation_hasher::handle_cache_entry):
>> Delete.
>> (value_annotation_hasher::keep_cache_entry): New function.
>> * gcc-interface/utils.c (pad_type_hasher::handle_cache_entry):
>> Delete.
>> (pad_type_hasher::keep_cache_entry): New function.
>>
>> gcc/
>> * hash-table.h (hash_table): Add gt_cleare_cache as a friend.
>> (gt_cleare_cache): Check here for deleted and empty entries.
>> Replace handle_cache_entry with a call to keep_cache_entry.
>> * hash-traits.h (ggc_cache_hasher::handle_cache_entry): Delete.
>> (ggc_cache_hasher::keep_cache_entry): New function.
>> * trans-mem.c (tm_wrapper_hasher::handle_cache_entry): Delete.
>> (tm_wrapper_hasher::keep_cache_entry): New function.
>> * tree.h (tree_decl_map_cache_hasher::handle_cache_entry): Delete.
>> (tree_vec_map_cache_hasher::keep_cache_entry): New function.
>> * tree.c (type_cache_hasher::handle_cache_entry): Delete.
>> (type_cache_hasher::keep_cache_entry): New function.
>> (tree_vec_map_cache_hasher::handle_cache_entry): Delete.
>> (tree_vec_map_cache_hasher::keep_cache_entry): New function.
>> * ubsan.c (tree_type_map_cache_hasher::handle_cache_entry): Delete.
>> (tree_type_map_cache_hasher::keep_cache_entry): New function.
>> * varasm.c (tm_clone_hasher::handle_cache_entry): Delete.
>> (tm_clone_hasher::keep_cache_entry): New function.
>> * config/i386/i386.c (dllimport_hasher::handle_cache_entry): Delete.
>> (dllimport_hasher::keep_cache_entry): New function.
> So for all the keep_cache_entry functions, I guess they're trivial
> enough that a function comment probably isn't needed.
Yeah. For cases like this where the function is implementing a defined
interface (described in hash-table.h), I think it's better to only have
comments for implementations that are doing something non-obvious.
> Presumably no good way to share the trivial implementation?
Probably not without sharing the other parts of the traits in some way.
That might be another possible cleanup :-)
Thanks,
Richard