Review decision to inline mempcpy to memcpy.

[Carlos O'Donell]

On 03/03/2016 03:55 PM, H.J. Lu wrote:
> On Thu, Mar 3, 2016 at 7:23 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> 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 opened:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=19759

I think x86_64 should define  
#define _HAVE_STRING_ARCH_mempcpy 1 in string.h?

That way the inline is avoided.

HJ, Can you show that doing that gives a speedup?

The point Ondrej makes in his original emails is that
using the inline gave better performance on x86_64.
Should we ignore such findings? Or are the microbenchmarks
we have insufficient to show the overall gains we're
talking about (in terms of the register usage)?

That is to say, should the change be made simply from
first principles that it's a good change, or do we need
a performance justification?

Cheers,
Carlos.