Re: [PATCH] Optimize MIPS memcpy

[Steve Ellcey <sellcey at mips dot com>]

On Sat, 2012-10-06 at 17:43 +1300, Maxim Kuvyrkov wrote:

> Steve and I have debugged these failures and they now seem to be resolved.  I'll let Steve to followup with analysis and a new patch.
> 
> Meanwhile, I've benchmarked Steve's patch against mine.  On the benchmark that I use both implementations provide equal performance for N64 ABI, but on N32 ABI Steve's patch is only half as fast.  This is, probably, due to using 4-byte operations instead of 8-byte operations for N32 ABI:
> 
> #if _MIPS_SIM == _ABI64
> #define USE_DOUBLE
> #endif
> 
> It should be easy to improve Steve's patch for N32 ABI.  Steve, will you look into that?
> 
> I would also appreciate if you look into making your version of memcpy memmove-safe, if it is not already.
> 
> Thank you,
> 
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics

Maxim, do you know if your test is doing a memcpy on overlapping memory?
While our analysis showed that the problem was due to the use of the
'prepare to store' prefetch hint, the code I sent earlier should have
worked fine for any code that was not doing an overlapping memcpy.

For anyone who may be interested, the 'prepare for store' prefetch hint
is different then other 'safe' prefetches which can be executed or
ignored without affecting the results of the code being executed. 

Instead of bringing a chunk of memory into the cache, it simply
allocates a line of cache for use and zeros it out.  If you write to
every byte of that line of cache, you are OK.  But if you use the
'prepare to store' cache hint and do not write to the entire cache line
then the bytes you don't write to get written back to memory as zeros,
overwriting whatever was there before.  The code in my memcpy routine
accounts for this, by checking the length of the buffer before doing the
'prepare to store' prefetches and only using them when it knows that it
is going to write to the entire cache line.

The other issue though is if the source and destination of the memcpy
overlap and if you use the prepare to store prefetch on a memory address
that is also part of the source of the memcpy you will get incorrect
results.  That means that if we want to have memcpy be 'memmove-safe'
we cannot use the 'prepare to store' hint.

I will fix the code to use double loads and stores with the N32 ABI
and add comments about the 'prepare to store' hint.  I hate to give up
on using the 'prepare for store' prefetch hint, since it does result in
the best peformance,  but given the various issues maybe it is not the
best idea for glibc.

Steve Ellcey
sellcey@mips.com