[U-Boot] [PATCH] lib/string: memmove: use memcpy if it is safe to do so

[Mike Frysinger]

On Fri, Oct 28, 2011 at 22:25, Wolfgang Denk wrote:
> Peter Korsgaard wrote:
>> memmove is used in a number of performance critical places, like copying the
>> linux kernel from nor flash to ram, so optimizing it can be interesting.
>>
>> Unfortunately, an arch specific version of memmove often isn't used, and
>> not supported at all on a number of archs (arm/mips/nds32/nios2/x86) -
>> But memcpy typically is.
>
> So you are adding code, making the system even less efficient?  This
> sounds to be acounter-productive approach.
>
> Can you not instead arrange for arch specific, optimized versions
> memmove() to be used?

i think this is kind of a loose-loose situation.  in common code, we
have to use memmove() if the two regions could *possibly* overlap.  so
in practice, we end up calling memmove() in more cases than strictly
necessary.  but the only real choice is to update all the call sites
with region overlap checks.

at least with Peter's patch, we centralize all these checks in one
place producing smaller code.  in some cases, we probably add a little
bit of runtime overhead when the new if() statement returns false, but
it seems to be that one successful call quickly outweighs multiple
unsuccessful if() checks.

i also think this falls into the same category as the previous commit
b038db852b5b7120f1ff825d8e2a5c2cd14c2f0f:
memcpy/memmove: Do not copy to same address

so the ideal probably would be to have an optimized memmove in place,
but for the (many) arches which don't have this, we seem to get a
"win" overall ?
-mike