This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping: [Patch] aarch64: Thunderx specific memcpy and memmove
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: <sellcey at cavium dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Wed, 3 May 2017 15:01:41 +0100
- Subject: Re: Ping: [Patch] aarch64: Thunderx specific memcpy and memmove
- Authentication-results: sourceware.org; auth=none
- Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <1493663254.29498.11.camel@cavium.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 01/05/17 19:27, Steve Ellcey wrote:
> This is a patch ping for the aarch64 IFUNC memcpy/memmove patch.
>
> https://sourceware.org/ml/libc-alpha/2017-03/msg00596.html
>
> I sent the glibc memcpy/memmove benchmark outputs to show the speedup
> and responded to Wainer's include syntax question. I don't have an
> answer for Szabolcs on whether we should just be doing prefetches on
> all platforms because I don't have other platforms to test on.
>
Wilco is still investigating how to add the prefetches to
the generic code (so thunderx does not need separate memcpy)
we will first post the patches on the newlib list (to avoid
copyright assignment issues) if we find a way to improve the
generic code.
if it turns out that a single generic memcpy does not work
it makes more sense to me to organize the code differently:
if we expect the generic memcpy to diverge from the thunderx
one then it's better not to use the same code with ifdefs, but
keep them separate, so the thunderx variant can be maintained
independently by whoever cares about thunderx.