[Patch, MIPS] Improve memcpy performance on MIPS

Corinna Vinschen vinschen@redhat.com
Sun Oct 25 18:31:00 GMT 2015

Hi Steve,

On Oct 21 10:05, Steve Ellcey  wrote:
> This patch improves the MIPS memcpy performance on small copies of aligned
> data.  It is identical to a patch I checked in to the GLIBC library.  The
> original issue was that someone noticed that the MIPS N32 (and N64) memcpy
> was slower than the MIPS O32 memcpy for small (less than 16 byte) aligned
> memcpy's.  This is because for sizes of 8 to 15 bytes, the O32 memcpy would
> do two or three word copies followed by byte copies but the N32 version would
> do all byte copies.  Basically, the N32 version did not 'fall back' to doing
> word copies when it could not do double-word copies.
> This patch addresses the problem with two changes.  One is actually for
> large memcpy's on N32.  After doing as many double-word copies as possible
> the N32 version will try do do at least one word copy before going to byte
> copies.
> The other change is that after determining that a memcpy is small (less than
> 8 bytes for O32 ABI, less than 16 bytes for N32 or N64 ABI), instead of just
> doing byte copies it will check the size and alignment of the inputs and,
> if possible, do word copies (followed by byte copies if needed).  If it is
> not possible to do word copies due to size or alignment it drops back to byte
> copies as before.
> I did some performance testing, including the glibc performance tests
> and for small memcpy's it showed that aligned data was being copied
> faster but unaligned data was being copied slower (due to the extra
> checks for alignment).
> See https://sourceware.org/ml/libc-alpha/2015-10/msg00597.html for
> the actual numbers.
> OK to check in?

Yes, please go ahead.


Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20151025/2911dd9b/attachment.sig>

More information about the Newlib mailing list