Re: [patch, mips, memmove] Remove memmove's use of memcpy on MIPS

[Chris Metcalf <cmetcalf at tilera dot com>]

On 1/25/2013 1:17 PM, Steve Ellcey wrote:
> While doing some other testing Maciej Rozycki found a bug in the MIPS
> memmove.  A few weeks ago (after the release of 2.17) I updated the MIPS
> memcpy.S to use the prepare-to-store prefetch instruction.  This makes
> memcpy (particularly long memcpy's) much faster.  The problem is that the
> prepare-to-store prefetch is not a 'real' prefetch, it doesn't read the
> memory into the cache but, if the data is not already in cache, it creates a
> cache line with all zeros and assumes that the user will write to the entire
> line.  If you try to read from that cache line or if you don't write to the
> entire cache line before it is flushed you will get bad results.

See ports/sysdeps/tile/tilegx/memcpy.c for how the tile architecture handles this issue.  The memcpy code advances until the destination pointer is cache-aligned, then loops cacheline at a time, first reading 64 bytes, then doing the prepare-to-store (aka "wh64"), then writing all 64 bytes.  This ensures that no matter what overlap the source has with the destination, we have captured any data that might be overwritten by the "wh64" instruction.  Since our memory architecture is non-blocking we can issue all eight reads without waiting for them to complete.

Would doing something like this for MIPS allow your memcpy to be safe for forward memmove?

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com