This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: bzero/bcopy/bcmp/mempcpy (was: Improve strncpy performance further)

Roland McGrath wrote:
> There are no uses of bcopy outside of tests, and portability macros in code
> (possibly, or once) shared with gnulib.  There is a bcopy macro in
> locale/programs/simple-hash.c, but it's not used anywhere.  I've removed
> that in the patch below.
> There are three uses of bzero outside of tests.  I've changed those to
> memset in the patch below.  In my build (x86_64-linux-gnu, GCC 4.8.3) this
> did not change the compiled code at all--so they were already being reduced
> to memset or inlined directly by the compiler.

GCC often expands bzero into memset, but not all versions do this, and neither
do all options, so you cannot rely on this. So before your patch login/logout.c 
might actually call bzero...

We need something like this in string.h so we always optimize all calls to
standard optimized functions, irrespectively of the compiler and options used:

#ifdef __USE_MISC
# define bzero(s, n) memset (s, '\0', n)
# define __bzero(s, n) memset (s, '\0', n)
# define bcopy(src, dest, n) memmove (dest, src, n)
# define bcmp(s1, s2) memcmp(s1, s2)

Does that seem reasonable?

Now the only remaining one to deal with is mempcpy - I'd like something like 
this in string/strings2.h:

#define mempcpy(dest, src, n) __mempcpy_inline (dest, src, n)
__STRING_INLINE void *__mempcpy_inline (void *dest, void *src, size_t n)
  return memcpy(dest, src, n) + n;

If there are targets which want to keep using their optimized version, then 
the above could be guarded by a define (eg. _HAVE_OPTIMIZED_MEMPCPY) which would 
be defined by any target which has an optimized mempcpy. Or is there an easier way
to test whether a target has added an optimized version of a generic function?

> Here's what I've just committed.  As I mentioned above, it caused no
> changes to the compiled code on x86_64-linux-gnu with gcc-4.8.3, except for
> the expected s/bcmp/memcmp/ changes that are trivially provably harmless.

Thanks, that looks good.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]