Re: [PATCH 11/20] alpha: add assembly mempcpy sharing the ev6 memcpy

On Thu, Aug 13, 2026 at 3:50 PM Wilco Dijkstra <[email protected]> wrote:
>
> Hi,
>
> > Do we really need to essentially duplicate the memcpy code for this optimization?
> > The alpha ABI cost us a bit more instruction for the function call (compare to
> > aarch64 for instance), but it does cost a lot less i-cache.
> >
> > The aarch64 uses the generic mempcpy.c and it seems not be a problem.
>
> It's not an optimization, in general it makes things worse (either slowing down
> a shared implementation or wasting L1 cache space for separate implementations).
>
> For this reason both GCC and LLVM optimize mempcpy into memcpy.
> Hence optimizing a mempcpy is completely missing the point since it will never
> be called. That's why the C version is fine.
>
> Cheers,
> Wilco

You're both right, dropping this one. I checked GCC: besides the
gimple fold (which only fires when the result is unused),
expand_builtin_mempcpy_args gates emitting a real mempcpy call on
targetm.libc_has_fast_function, which defaults to false and is
overridden only by i386.

So on alpha GCC always expands mempcpy to an inline copy or a memcpy
libcall plus an add of the length, regardless of whether the return
value is used. glibc's internal __mempcpy goes down the same path,
since include/string.h maps it to __builtin_mempcpy. The assembly
version would essentially never be called, so it's pure I-cache cost.
Dropping the patch and the two enabling changes to memcpy.S.

Thanks for setting me straight.