Re: [RFC] Do not call memmove when memcpy suffices.

[OndÅej BÃlka <neleai at seznam dot cz>]

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.