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

[Alexandre Oliva <aoliva at redhat dot com>]

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.

But then, we might as well expose this symbol to users.  Arguably,
memmove already is such exposed symbol and we shouldn't make a redundant
test when the caller has already determined that a specific mem copying
operation needs memmove.

What I'm getting at here is that, if we're going to do this, we should
probably have 3 entry points:

- memcpy: caller knows there's no overlap
- __memmove: caller knows there is an overlap
- memmove: caller doesn't know; test and call one of the above

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer