This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] aarch64: Optimized implementation of memmove for Qualcomm Falkor
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: siddhesh at sourceware dot org, libc-alpha at sourceware dot org
- Cc: nd at arm dot com
- Date: Thu, 05 Oct 2017 12:57:22 +0100
- Subject: Re: [PATCH] aarch64: Optimized implementation of memmove for Qualcomm Falkor
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <1505834450-21548-1-git-send-email-siddhesh@sourceware.org> <59D4E99C.9050500@arm.com> <fc7c4425-fb79-1329-4f04-1d9bb21bd7ae@sourceware.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 05/10/17 05:05, Siddhesh Poyarekar wrote:
> On Wednesday 04 October 2017 07:31 PM, Szabolcs Nagy wrote:
>> i think adding a falkor specific memmove is ok,
>> can you expand on why is it difficult to share code
>> between memcpy and memmove?
>
> The algorithms for memmove and memcpy are quite different, from the copy
> loop sizes to prefetching behaviour because of the memmove requirement
> to work on overlaps. Using multiple registers in memmove to expand the
> copy look to the memcpy size regresses performance for memmove while
> reducing the copy loop size in memcpy regresses memcpy, so it doesn't
> make sense to try and unify the implementations.
>
i'd expect memmove to do the same thing as memcpy
if there is no overlap or the overlap is dst < src.
why memcpy is not optimal for those cases?
i don't quite understand the prefetching and loop
size problems.
i think sharing code between memmove and memcpy is
useful for instruction cache and code maintenance too.
if that cannot be done for some reason then that
should be spelled out more clearly in the commit
message.