This is the mail archive of the
mailing list for the glibc project.
Re: [RFC PATCH] aarch64: improve memset
- From: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, will dot newton at linaro dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 11 Nov 2014 13:05:08 +0000
- Subject: Re: [RFC PATCH] aarch64: improve memset
- Authentication-results: sourceware.org; auth=none
- References: <002701cffaa0$77623570$6626a050$ at com> <002801cffaa5$eb2852f0$c178f8d0$ at com>
On 7 November 2014 16:14, Wilco Dijkstra <firstname.lastname@example.org> wrote:
>> Richard Henderson wrote:
> I've got a few comments on this patch:
> * Do we really need variants for cache line sizes that are never going to be used?
> I'd say just support 64 and 128, and default higher sizes to no_zva.
We shouldn't be removing support for the other sizes already supported
by the existing implementation. If the other sizes were deprecated
from the architecture then fair game, but that is not the case. From
offline conversation with Wilco I gather part of the motivation to
remove is that the none 64 cases cannot be readily tested on HW.
That particular issue was solved in the original implementation using
a hacked qemu.
> * Why special case line size=64 only? Unrolling might not help for 128 but should not
> harm either, and the alignment overhead only increases with larger line sizes, so you
> want to bypass the zva code in all cases if N < 3-4x line size.
> * Is the no-ifunc variant still required/used? We're now having at least 4 different
> variants which all need to be tested and maintained...
> * Finally, which version is used when linking statically? I presume there is some
> makefile magic that causes the no-zva version to be used, however that might not be
> optimal for all targets.