This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, MIPS] Modify memcpy.S for mips32r6/mips64r6

On Tue, Dec 23, 2014 at 11:15:02PM +0000, Matthew Fortune wrote:
> OndÅej BÃlka <>  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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]