This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Patch, MIPS] Modify memcpy.S for mips32r6/mips64r6
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, Steve Ellcey <Steve dot Ellcey at imgtec dot com>, Joseph Myers <joseph at codesourcery dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 24 Dec 2014 15:30:36 +0100
- Subject: Re: [Patch, MIPS] Modify memcpy.S for mips32r6/mips64r6
- Authentication-results: sourceware.org; auth=none
- References: <7ec2bf7e-fc1e-428b-ac0a-747f2a3ab3e6 at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 2 dot 10 dot 1412221758190 dot 5278 at digraph dot polyomino dot org dot uk> <1419354526 dot 27606 dot 73 dot camel at ubuntu-sellcey> <5499ABF8 dot 3060307 at twiddle dot net> <20141223203046 dot GA11362 at domone> <6D39441BF12EF246A7ABCE6654B0235320F8EC24 at LEMAIL01 dot le dot imgtec dot org>
On Tue, Dec 23, 2014 at 11:15:02PM +0000, Matthew Fortune wrote:
> OndÅej BÃlka <neleai@seznam.cz> writes:
> > On Tue, Dec 23, 2014 at 09:52:56AM -0800, Richard Henderson wrote:
> > >
> > Do you have that hardware? I already objected versus table but do not
> > have data. I wouldn't be surprised if its slower than byte-by-byte copy
> > with if after each byte. Or just copy 8 bytes without condition but I am
> > not sure how hardware handles overlapping stores. Difference will be
> > bigger in practice, in profiling around 50% calls are 8 byte aligned and
> > you save address calculation cost on these.
>
> I think Richard's idea is good but I do agree with Steve that the tried and
> tested code should go in first and then optimise it. There is lots of
> exploration to do with MIPSR6 and there are many new ways to optimize. If
> we don't have R6 support in glibc 2.21 then there is a definite performance
> regression on R6 as the R5/R2 code will trap and emulate on an R6 core making
> any non-trapping code several orders of magnitude better.
>
> Overall we are trying to hit as many package release dates as possible to
> provide everyone with initial R6 support for experimentation. For GLIBC that
> not only includes all the specific R6 patches from Steve but also requires
> the .MIPS.abiflags (FPXX/FP64 ABI) patch from myself.
>
That is valid argument. If that is objective then KISS when sending
patch as it will be easier to review and modify. When you try to add
optimizations you could expect comments that there is better way to
optimize it.