This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Do not call memmove when memcpy suffices.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 16 Aug 2013 21:44:14 +0200
- Subject: Re: [RFC] Do not call memmove when memcpy suffices.
- References: <20130813111123 dot GA1623 at domone dot kolej dot mff dot cuni dot cz> <orvc39xsd4 dot fsf at livre dot home>
On Tue, Aug 13, 2013 at 05:12:23PM -0300, Alexandre Oliva wrote:
> On Aug 13, 2013, OndÅej BÃlka <neleai@seznam.cz> wrote:
>
> > char *dest = (_dest);
> > char *src = (_src);
> > size_t n = (_n);
>
> dest, src and n are in the user namespace; we have to use symbols in the
> implementation namespace.
>
> > if (__glibc_likely ((size_t)((src - n) - dest) >= 2 * n))
>
> Is this test really safe? I'm thinking about arches with segmented
> memory and stuff, so that the difference between unrelated pointers may
> not make much sense or even fit in a size_t. I'm not sure we support
> any such architecture.
>
> > return memmove (dest, src, n);
>
> If we take this route of optimizing memmove with a macro, we'll probably
> want a distinct symbol to signal that we have already determined that
> there's an overlap and we need the extra complexity, rather than calling
> a function that might perform the test again.
>
A more fundamental problem is that I looked how is memmove used on my
system. I added counter what is probability of overlap. Just in firefox
it is
Success probability: 33.95%
a profile here
http://kam.mff.cuni.cz/~ondra/memmove_firefox_result/result.html
I assumed for header that overlaps are rare which is not case here.
I got a result by profiler that is here
http://kam.mff.cuni.cz/~ondra/benchmark_string/memmove_profile160813.tar.bz2
and by running
make
LD_PRELOAD=./libc_profile.so firefox # browse few pages and then close it.
make rep
then copied results directory.