This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/4] S390: Implement mempcpy with help of memcpy. [BZ #19765]

On Wed, May 4, 2016 at 1:58 PM, Adhemerval Zanella
<> 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
> ports.

Please don't enable it for x86.  Calling memcpy means we have to
save and restore 2 registers for no good reasons.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]