This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 4/4] S390: Implement mempcpy with help of memcpy. [BZ #19765]
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, nd <nd at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 5 May 2016 11:15:55 -0300
- Subject: Re: [PATCH 4/4] S390: Implement mempcpy with help of memcpy. [BZ #19765]
- Authentication-results: sourceware.org; auth=none
- References: <AM3PR08MB00888058CAFD723F21D2342D837B0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com> <572A3B9C dot 3080803 at linaro dot org> <AM3PR08MB00882DA2CEDFC95A1BB79776837B0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com> <572A6271 dot 6050802 at linaro dot org> <CAMe9rOrcKzp_bk__3iYxROBdi9=DOSw3HzrZsUrEYCSXXVtCmg at mail dot gmail dot com>
On 05/05/2016 10:37, H.J. Lu wrote:
> On Wed, May 4, 2016 at 1:58 PM, Adhemerval Zanella
> <firstname.lastname@example.org> wrote:
>> On 04/05/2016 17:51, Wilco Dijkstra wrote:
>>> 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...
>> But the current one at string/string.h is only enabled with !defined _HAVE_STRING_ARCH_mempcpy,
>> so if a port actually adds a mempcpy one it won't be enabled. What I am trying to argue it
>> to just remove the !defined _HAVE_STRING_ARCH_mempcpy and enable it as default for all
> Please don't enable it for x86. Calling memcpy means we have to
> save and restore 2 registers for no good reasons.
Yes, direct call will require save and restore the size for further add
and this is true for most architectures. My question is if does this
really matter in currently GLIBC internal usage and on programs that
might use it compared against the burden of keeping the various
string*.h header in check for multiple architectures or adding this
logic (mempcpy transformation to memcpy) on compiler.
But I understand in the end is up to arch maintainer to add or not such