This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] Optimize MIPS memcpy
- From: Maxim Kuvyrkov <maxim at codesourcery dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: Andrew T Pinski <pinskia at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, <libc-ports at sourceware dot org>
- Date: Sat, 6 Oct 2012 17:43:39 +1300
- Subject: Re: [PATCH] Optimize MIPS memcpy
- References: <5044746c.23eb440a.75e2.618f@mx.google.com> <1346771341.14333.20.camel@ubuntu-sellcey> <596797ED-6575-456D-98FD-C13A209DBC49@mentor.com> <1346948701.14333.152.camel@ubuntu-sellcey> <F265181B-6B5C-401B-B7CC-DC206B601795@codesourcery.com> <1347376645.14333.319.camel@ubuntu-sellcey> <F0856A02-839F-45C7-BF93-AA59E030A015@codesourcery.com> <1348166309.6170.55.camel@ubuntu-sellcey> <25105334-8813-4532-AC0E-B3A44BE69A19@codesourcery.com>
On 28/09/2012, at 3:47 PM, Maxim Kuvyrkov wrote:
> On 21/09/2012, at 6:38 AM, Steve Ellcey wrote:
>
>> On Thu, 2012-09-20 at 21:05 +1200, Maxim Kuvyrkov wrote:
>>
>>> What testing was done for this patch, does it pass glibc testsuite?
>>>
>>> I have a benchmark that exercises various string and mem* routines failing with it.
>>>
>>> Thank you,
>>>
>>> --
>>> Maxim Kuvyrkov
>>> CodeSourcery / Mentor Graphics
>>
>> Is the benchmark anything you can share? I ran the glibc testsuite and
>> got some failures but I don't think they are due to the new memcpy. I
>> am going back now and running the glibc testsuite with no changes to get
>> a baseline so I can verify that. Hopefully I will have an answer later
>> today.
>>
>> I ran some other tests like the gcc testsuite using a glibc with this
>> change in it and that didn't have any problems and there is the one I
>> sent to the list
>> http://sourceware.org/ml/libc-ports/2012-09/msg00007.html that also ran
>> with no problems.
>
> As I mentioned in a different email, I can't share the benchmark, but I think I've got a testcase of sorts for you to investigate. It appears your memcpy clobbers a couple of bytes just before DEST in certain cases.
>
> In particular when ABI=N32, DEST=0x10060008, SRC=0x1002c088, N=0x172 it clobbers DEST[-1] and DEST[-2] bytes.
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