This is the mail archive of the libc-alpha@sourceware.org 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] Inline mempcpy


On Wed, 13 May 2015, Ondřej Bílka wrote:

> Hi,
> As pointed out that following patch should be generic
> http://patchwork.sourceware.org/patch/6459/
> here is sample patch that does it. Header for mempcpy now becomes
> following:
> 
> #ifdef __USE_GNU
> # if !defined _HAVE_STRING_ARCH_mempcpy || defined _FORCE_INLINES

Doesn't this change the semantics of _HAVE_STRING_ARCH_mempcpy?  That is, 
after this patch, architectures with efficient .S implementations of 
mempcpy (as opposed to ones that just use the default .c implementation) 
should define that macro rather than just those with inline 
implementations.  So the patch needs to update architectures as well.

> Patch itself is messy as it also removes obsolete inlining for gcc-3.4
> and older. Ok to clean that up or should I send separate patch to remove
> all obsolete inlines from string2.h. These would also cause regression
> as implementations improved a lot and inlines there use only 32bit
> access without using 64bit capabilities.

Did the discussion involving 
<https://sourceware.org/ml/libc-alpha/2013-01/msg00157.html> and 
<https://sourceware.org/ml/libc-alpha/2013-01/msg00270.html> reach any 
wiki-documented consensus regarding what compiler versions it's worth 
having any optimizations for in the headers?

-- 
Joseph S. Myers
joseph@codesourcery.com

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