This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] PPC64 memcpy
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Paul Mackerras <paulus at samba dot org>, libc-alpha <libc-alpha at sources dot redhat dot com>
- Date: Wed, 19 Mar 2003 10:16:04 +0100
- Subject: Re: [PATCH] PPC64 memcpy
- References: <OF2B71EA52.8F31D776-ON86256CEE.0012B8A8-86256CEE.firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Mar 18, 2003 at 09:31:42PM -0600, Steve Munroe wrote:
> Paul MacKerras writes:
> > > + cmpldi cr1,5,31
> > > + neg 0,3
> > etc...
> > Any particular reason why you used the bare register numbers instead
> > of the 'r' names (e.g. r0, r3, etc.)?
> Because the original was generated -S via inline asm in powerpc64/memcopy.h
> and generic/memcpy.c. The problem is that memcopy.h macros are shared
> between memmove.c and memcpy.c and my optimization for memcpy does not
> allow overlapping fields which is requires for memmove.
FYI there are tons of broken apps out there which use memcpy where memmove
is required. I had to avoid using alphaev6 memcpy.S in the past because
the number of application bugs was too high.
Maybe #ifndef NDEBUG we could check memcpy arguments and abort if they