This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Inline mempcpy
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 14 May 2015 09:21:59 +0200
- Subject: Re: [PATCH] Inline mempcpy
- Authentication-results: sourceware.org; auth=none
- References: <20150513192819 dot GA1170 at domone> <alpine dot DEB dot 2 dot 10 dot 1505132210200 dot 29221 at digraph dot polyomino dot org dot uk>
On Wed, May 13, 2015 at 10:21:25PM +0000, Joseph Myers wrote:
> On Wed, 13 May 2015, OndÅej BÃlka wrote:
>
> > Hi,
> > As pointed out that following patch should be generic
> > http://patchwork.sourceware.org/patch/6459/
> > here is sample patch that does it. Header for mempcpy now becomes
> > following:
> >
> > #ifdef __USE_GNU
> > # if !defined _HAVE_STRING_ARCH_mempcpy || defined _FORCE_INLINES
>
> Doesn't this change the semantics of _HAVE_STRING_ARCH_mempcpy? That is,
> after this patch, architectures with efficient .S implementations of
> mempcpy (as opposed to ones that just use the default .c implementation)
> should define that macro rather than just those with inline
> implementations. So the patch needs to update architectures as well.
>
Read the friendly thread. In short you should always expand mempcpy to
memcpy and keep mempcpy implementation just for legacy programs.
Possible benefits are small, few cycles to save register spill at most.
It can't be better as you can implement memcpy with mempcpy.
But there is huge cost involved. Effective mempcpy is often larger than
one kilobyte. Duplicating that kilobyte for mempcpy would increase
instruction cache pressure a lot. Easily it could cause one cache miss
per call resulting additional 30 cycle penalty negating any benefit you
try to make.