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

[David Laight <david.laight.linux@gmail.com>]

On Fri, 13 Nov 2026 09:34:26 -0800
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.

Actually you could detect the 'small constant sizes' and call the real
memcpy for them.
The compiler would then (hopefully) inline them as a series of moves.

> 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.

I had remembered about those, even if I didn't mention them.

> 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.

I knew you had wished that in the past.
It isn't as though it doesn't have other calls with (annoying)
non-standard calling conventions.
For one arch we optimise 'shift by count' with a jump table, and fall
foul of needing a scratch register - so have to spill to stack.

David

> 
> Without compiler support, we're kind of screwed.
> 
>               Linus
> 
>               Linus