GNU bug report logs - #46111
Reverting fns.c hash function due to OpenBSD/SPARC64 compile breaking

Previous Next

Full log

Message #77 received at 46111 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 46111 <at> debbugs.gnu.org, me <at> enzu.ru
Subject: Re: bug#46111: Reverting fns.c hash function due to OpenBSD/SPARC64
 compile breaking
Date: Thu, 28 Jan 2021 19:22:47 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 28 Jan 2021 11:17:31 -0500
> Cc: 46111 <at> debbugs.gnu.org
> 
> +      /* Here `p` is *almost* always be properly aligned, so we want to
> +         optimize for the aligned case, but we still need to support the
> +         non-aligned case.  */
> +      /* FIXME: Could we just always use `memcpy` and rely on GCC optimizing
> +         it to a single word-sized memory access on all-but-sparc64?  */
> +#ifdef __sparc64__  /* Arch that still insists on aligned memory accesses. */
> +      EMACS_UINT c;
> +      if (!((unsigned long)p) % sizeof (c))
> +        c = *p;
> +      else
> +        memcpy (&c, (char const *)p, sizeof (c)); /* `p` is unaligned!  */
> +#else
>        EMACS_UINT c = *p;
> +#fi

AFAIK, memcpy itself optimizes: once it gets to aligned address, it
starts copying words instead of bytes.  So I'm not sure we need either
#ifdef or the run-time condition.  I suggest to time both variants on
x86 architecture, to see whether there's any performance hit due to
use of memcpy, and if not, use memcpy always -- it will let us have
the cake and eat it, too.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.