[RFC PATCH 12/19] riscv: Add accelerated memcpy/memmove routines for RV64

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Adhemerval,

> The generic routines still assumes that hardware can't or is prohibitive 
> expensive to issue unaligned memory access.  However, I think we move toward 
> this direction to start adding unaligned variants when it makes sense.

There is a _STRING_ARCH_unaligned define that can be set per target. It needs
cleaning up since it's used mostly for premature micro-optimizations (eg. getenv.c)
where using a fixed size memcpy would be best (it also appears to have big-endian
bugs).

> Another usual tuning is loop unrolling, which depends on underlying hardware.
> Unfortunately we need to explicit force gcc to unroll some loop construction
> (for instance check sysdeps/powerpc/powerpc64/power4/Makefile), so this might
> be another approach you might use to tune RISCV routines.

Compiler unrolling is unlikely to give improved results, especially on GCC where
the default unroll factor is still 16 times which will just bloat the code...
So all reasonable unrolling is best done by hand (and doesn't need to be target
specific).

> The memcpy, memmove, memset, memcmp are a slight different subject.  Although
> current generic mem routines does use some explicit unrolling, it also does
> not take in consideration unaligned access, vector instructions, or special 
> instruction (such as cache clear one).  And these usually make a lot of
> difference.

Indeed. However it is also quite difficult to make use of all these without a lot of
target specific code and inline assembler. And at that point you might as well use
assembler...

> What I would expect it maybe we can use a similar strategy Google is doing
> with llvm libc, which based its work on the automemcpy paper [1]. It means
> that for unaligned, each architecture will reimplement the memory routine
> block.  Although the project focus on static compiling, I think using hooks
> over assembly routines might be a better approach (you might reuse code
> blocks or try different strategies more easily).
>
> [1] https://storage.googleapis.com/pub-tools-public-publication-data/pdf/4f7c3da72d557ed418828823a8e59942859d677f.pdf

I'm still not convinced about this strategy - it's hard to beat assembler using
generic code. The way it works in LLVM is that you implement a new set of
builtins that inline an optimal memcpy for a fixed size. But you don't know the
alignment, so this only works on targets that support fast unaligned access.
And with different compiler versions/options you get major performance
variations due to code reordering, register allocation differences or failure
to emit load/store pairs...

I believe it is reasonable to ensure the generic string functions are efficient
to avoid having to write assembler for every string function. However it
becomes crazy when you set the goal to be as close as possible to the best
assembler version in all cases. Most targets will add assembly versions for
key functions like memcpy, strlen etc.

Cheers,
Wilco