This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add ifunc memcpy and memmove for aarch64
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, "sellcey at caviumnetworks dot com" <sellcey at caviumnetworks dot com>
- Cc: "adhemerval dot zanella at linaro dot org" <adhemerval dot zanella at linaro dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Tue, 7 Feb 2017 18:31:01 +0530
- Subject: Re: [PATCH] Add ifunc memcpy and memmove for aarch64
- Authentication-results: sourceware.org; auth=none
- References: <AM5PR0802MB2610A11854986B9A53EBC68783430@AM5PR0802MB2610.eurprd08.prod.outlook.com>
On Tuesday 07 February 2017 06:12 PM, Wilco Dijkstra wrote:
> I agree we want to avoid using conditional compilation as much as possible.
> On the other hand duplication is a bad idea too, I've seen too many cases where
> bugs were only fixed in one of the N duplicates.
Sure, but then in that case the de-duplication must be done by
identifying a logical code block and make that into a macro to override
and not just arbitrarily inject hunks of code. So in this case it could
be alternate implementations of copy_long that is sufficient so #define
COPY_LONG in both memcpy_generic and memcpy_thunderx and have the parent
(memcpy.S) use that macro. In fact, that might even end up making the
code a bit nicer to read.
> However I'm actually wondering whether we need an ifunc for this case.
> For large copies from L2 I think adding a prefetch should be benign even on
> cores that don't need it, so if the benchmarks confirm this we should consider
> updating the generic memcpy.
That is a call that ARM maintainers can take and is also another reason
to separate the IFUNC infrastructure code from the thunderx change.
Siddhesh