Review decision to inline mempcpy to memcpy.

["Carlos O'Donell" <carlos at redhat dot com>]

The upstream gcc PR/70055 requests that glibc revert commit
05a910f7b420c2b831f35ba90e61c80f001c0606 and instead work
with gcc to make the builtin mempcpy better (for various
aspects of performance).

The crux of the argument is that the compiler may be able
to do a better job of optimizing if it knows the call was
a mempcpy as opposed to memcpy + addition.

I understand the need of glibc machine maintainers to produce
a library whose performance is as optimal as they can given
the compilers we have today. This leads to decisions like those
we made to transform mempcpy to memcpy + addition.

I also understand the worries that the compiler developers see
in such a transformation. Information has been lost to the
compiler that might generated better code.

Is there a middle ground here? Should machines with mempcpy.S,
particularly x86_64 define _HAVE_STRING_ARCH_mempcpy in their
string.h? I think this question wasn't clearly answered before
the patch went in. However, the microbenchmarks show this is
a clear gain given modern compilers for x86_64. Is this because
x86_64's mempcpy.S is flawed? Does it need to be fixed as
opposed to transforming mempcpy to memcpy+addition?

Ondrej,

Did you file gcc bugs to revuew the optimization issues
with current mempcpy as suggested in [2] and [3]?

Wilco,

Were the changes in glibc to optimize mempcpy as memcpy
originally motivated by performance for ARM?

Particularly because ARM does not have an optimized
mempcpy implementation in glibc?

Cheers,
Carlos.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
[2] https://sourceware.org/ml/libc-alpha/2015-05/msg00778.html
[3] https://sourceware.org/ml/libc-alpha/2015-05/msg00780.html