This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/4] Add an abstract incremental hash data type
- From: Jeff Law <law at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>, gcc-patches at gcc dot gnu dot org
- Cc: Andi Kleen <ak at linux dot intel dot com>
- Date: Tue, 22 Jul 2014 21:34:39 -0600
- Subject: Re: [PATCH 1/4] Add an abstract incremental hash data type
- Authentication-results: sourceware.org; auth=none
- References: <1405488709-12677-1-git-send-email-andi at firstfloor dot org> <1405488709-12677-2-git-send-email-andi at firstfloor dot org>
On 07/15/14 23:31, Andi Kleen wrote:
From: Andi Kleen <ak@linux.intel.com>
Some files in gcc, like lto or tree, do large scale incremential hashing.
The current jhash implementation of this could be likely improved
by using an incremential hash that does not do a full rehashing
for every new value added.
This patch adds a new "inchash" class that abstracts the internal
state of the hash. This makes it easier to plug in new hashes
and also cleans up the code a bit.
Right now it is just implemented in the same way as the old
iterative hash in tree.c. The previous iterative hash code
from tree.c moved into a new separate file. Also I fixed up all
users to include the new header.
It should not really change any hashing by itself, it's just
a cleanup at this point.
gcc/:
2014-07-10 Andi Kleen <ak@linux.intel.com>
* Makefile.in (OBJS): Add inchash.o.
(PLUGIN_HEADERS): Add inchash.h.
* ipa-devirt.c: Include inchash.h.
* lto-streamer-out.c: Dito.
* tree-ssa-dom.c: Dito.
* tree-ssa-pre.c: Dito.
* tree-ssa-sccvn.c: Dito.
* tree-ssa-tail-merge.c: Dito.
* asan.c: Dito.
* tree.c (iterative_hash_hashval_t): Move to ...
(iterative_hash_host_wide_int): Move to ...
* inchash.c: Here. New file.
* tree.h (iterative_hash_hashval_t): Move to ...
(iterative_hash_host_wide_int): Move to ...
* inchash.h: Here. New file.
If there isn't any concrete benefit from using explicit begin/end, I'd
just initialize the data in the ctor.
Otherwise, this is a fine cleanup.
Presumably there's going to be some better hashing functions coming down
the pipe?
Jeff