This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/4] S390: Implement mempcpy with help of memcpy. [BZ #19765]
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: nd <nd at arm dot com>, 'GNU C Library' <libc-alpha at sourceware dot org>
- Date: Wed, 4 May 2016 20:51:11 +0000
- Subject: Re: [PATCH 4/4] S390: Implement mempcpy with help of memcpy. [BZ #19765]
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <AM3PR08MB00888058CAFD723F21D2342D837B0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com>,<572A3B9C dot 3080803 at linaro dot org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
Adhemerval Zanella wrote:
>
> But my point is all the architectures which provide an optimized mempcpy is
> though either 1. jump directly to optimized memcpy (s390 case for this patchset),
> 2. clonning the same memcpy implementation and adjusting the pointers (x86_64) or
> 3. using a similar strategy for both implementations (powerpc).
Indeed, which of those are used doesn't matter much.
> So for this change I am proposing compiler support won't be required because both
> memcpy and __mempcpy will be transformed to memcpy + s. Based on assumption that
> memcpy is fast as mempcpy implementation I think there is no need to just add
> this micro-optimization to only s390, but rather make is general.
GLIBC already has this optimization in the generic string header, it's just that s390 wants
to do something different again. As long as GCC isn't fixed this isn't possible to support
s390 without this header workaround. And we need GCC to improve so things work
better for all the other C libraries...
In an ideal world mempcy and friends should never have been introduced as micro
optimizations, they just cause performance and maintenance headaches for no actual
benefit...
Wilco