[PATCH] x86_64: Align memmove unaligned routines to 64 byte

[Sunil Pandey]

On Wed, May 29, 2024 at 11:34 AM Noah Goldstein <goldstein.w.n@gmail.com>
wrote:

> On Wed, May 29, 2024 at 1:26 PM Sunil Pandey <skpgkp2@gmail.com> wrote:
> >
> >
> >
> > On Wed, May 29, 2024 at 11:06 AM Noah Goldstein <goldstein.w.n@gmail.com>
> wrote:
> >>
> >> On Wed, May 29, 2024 at 11:37 AM Sunil K Pandey <skpgkp2@gmail.com>
> wrote:
> >> >
> >> > This patch align memmove unaligned routines to 64 byte.  Default 16
> byte
> >> > alignment may cause upto 15% random perf regression for less than
> vector
> >> > size memmove.
> >> > ---
> >> >  sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
> b/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
> >> > index 838f8f8bff..85c0efd9e3 100644
> >> > --- a/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
> >> > +++ b/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
> >> > @@ -207,7 +207,7 @@ ENTRY (MEMMOVE_CHK_SYMBOL (__memmove_chk,
> unaligned))
> >> >  END (MEMMOVE_CHK_SYMBOL (__memmove_chk, unaligned))
> >> >  #endif
> >> >
> >> > -ENTRY (MEMMOVE_SYMBOL (__memmove, unaligned))
> >> > +ENTRY_P2ALIGN (MEMMOVE_SYMBOL (__memmove, unaligned), 6)
> >> >         movq    %rdi, %rax
> >> >  L(start):
> >> >  # ifdef __ILP32__
> >> > --
> >> > 2.44.0
> >> >
> >>
> >> Isn't the erms nearly always used?
> >
> >
> > It's used in libMicro benchmark.
> > https://github.com/redhat-performance/libMicro
>
> Im not contending that if you microbenchmark this it won't be faster
> if it's 64 byte aligned.
>
> The question is outside of microbenchmarks is this impl important
> enough to optimize?
>

There are people who rely on this benchmark data for their hardware/software
decision.

So, if this implementation is there and we can easily optimize, we should.
If nothing else, it can reduce their random regression troubleshooting time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240529/52e003f3/attachment.htm>