Re: ARM memcpy post-0.9.12-release thread

[Rich Felker <dalias@aerifal.cx>]

On Sat, Aug 03, 2013 at 10:03:14AM +1200, Andre Renaud wrote:
> Hi Rich,
> 
> On 3 August 2013 08:41, Rich Felker <dalias@aerifal.cx> wrote:
> > Andre, do you have any input on this? (Cc'ing)
> >
> > Rich
> 
> Sorry, I've been reading the emails, but haven't had a chance to get
> back to the code. I don't really have an opinion on the gcc memcpy
> issue, however I was still hopeful that we could come up with a
> relatively clean mixed C/asm solution for the misaligned/non-congruent
> copy scenario. Having said that, I haven't done anything on it yet.
> 
> To be honest, although a solution probably exists, I doubt it's ever
> going to be much better than the bionic code (with the exception of
> possibly being less to read).

I'm not sure about the "less to read" either. I would very much _like_
some generic C code for this, since the same basic strategy is
applicable to all RISC-y archs with lots of registers but no
misaligned memory access:

1. Read several aligned words.
2. Bitshift them with carry to adjust for the relative misalignment
   of the destination.
3. Write several aligned words.

Unfortunately what this amounts to is N-1, where N is the alignment (4
for ARM, 8 for 64-bit-register archs), versions of the misaligned copy
code, one for each value of (dest-src)%N.

Oh, and you need separate cases for little and big endian too, since
the bitshifts work with values rather than just representations.

My guess is that at best we'll only get about 80% of the performance
of the bionic asm, but I could be pleasantly surprised. What makes it
nice is that this could get us acceptable memcpy performance on mips,
powerpc, microblaze, etc. without having to write assembly for them
all.

I'll probably add the bionic asm for now, but I can't do it without
first adding a way to disable it for "armeb".

Rich