[PATCH] aarch64: Optimized implementation of memmove for Qualcomm Falkor

Szabolcs Nagy szabolcs.nagy@arm.com
Thu Oct 5 11:57:00 GMT 2017


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.



More information about the Libc-alpha mailing list