Re: [PATCH v3 2/2] x86/lib: Use REP MOVSB for large memcpy() on ERMS CPUs without FSRM

["H. Peter Anvin" <hpa@zytor.com>]

On November 13, 2026 9:34:26 AM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Fri, 13 Nov 2026 at 08:03, David Laight <david.laight.linux@gmail.com> wrote:
>>
>> I was thinking more of something like:
>> (written in the email so untested)
>>
>> static always_inline void *memcpy(void *dst, const void *src, size_t len)
>
>The problem with this approach two-fold:
>
> - many memcpy() calls aren't actually memcpy() calls on a C level
>
> - many memcpy() that *are* calls on a C level should never be calls
>in the generated code
>
>That first case is for things like structure copies etc. And it's
>common, and it's important, although for the kernel it's usually a
>non-issue because it's *typicay* a small constant-sized copy, which
>brings us to the second case...
>
>The second case is hugely important. The compiler needs to turn small
>memcpy() calls into just loads and stores. Calling "memcpy()" for a
>known 64-byte copy is hugely inefficient.
>
>We used to - long ago - do that "constant small sizes" thing by hand.
>It was a huge pain. We now rely on the compiler to do it.
>
>End result: we must *not* hide 'memcpy()' from the compiler for
>performance reasons, and we cannot catch all cases anyway because the
>compiler generates implicit memcpy calls.
>
>This is why I really wish we had the compiler just generate a
>different sequence for 'call memcpy'. One that used a different
>callign convention - preferably just the 'rep movs' one so that we
>could just rewrite the call with 'rep movsb' in place.
>
>Without compiler support, we're kind of screwed.
>
>              Linus
>
>              Linus

Well, we can put a request in for compiler support. This equally applies to other compiler runtime functions, for that matter...