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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
