This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Strengthen ICF hash
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, mliska at suse dot cz
- Date: Wed, 4 Mar 2015 14:51:46 +0100
- Subject: Re: Strengthen ICF hash
- Authentication-results: sourceware.org; auth=none
- References: <20150301214405 dot GB95914 at kam dot mff dot cuni dot cz> <87wq30tah7 dot fsf at tassilo dot jf dot intel dot com> <20150303072545 dot GA84757 at kam dot mff dot cuni dot cz> <20150304131959 dot GK823 at two dot firstfloor dot org>
On Wed, Mar 4, 2015 at 2:20 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Hi Honza,
>
> Regarding modern hash functions, as far as I understand the trend
> is to just stop doing anything fancy and just use the CRC instructions
> in modern CPUs
I wonder if we can use intrinsics for CRC in place of the
existing iterative_hash_hashval_t (and thus the 'mix' macro)?
Similar to how we optimize libcpp? Seems like
#define mix(a,b,c) \
c = _mm_crc32_u32 (b, c)
would do? And for iterative_hash_host_wide_int use _mm_crc32_u64?
(libcpp seems to use GCC target builtins, not intrinsics though,
see init_vectorized_lexer)
Thanks,
Richard.
> (unless you need a somewhat cryto hash to guard against
> DoS attacks). spooky doesn't do that though, it's just a highly
> optimized classical hash. It's much more stream lined than the somewhat
> weird iterative hash construction that standard gcc uses, and I suspect
> has better avalance effect. Also it'll do much less work per bit
> (at the cost of larger code)
>
>> Said all that I would be very curious if actual stronger hading would help.
>> I saw some miscompares for stuff that should be covered by hash. I will try
>> to get some stats soon.
>
> I sent you the spooky patches in separate mail. I did a quick test run
> and they don't seem to regress anything.
>
> -Andi