[PATCH 0/3] RISC-V: memcpy(): align dest when misaligned access is

Mahmoud Abumandour ma.mandourr@gmail.com
Mon May 26 14:42:57 GMT 2025


Hello,

Those patches were reviewed a while ago but have not been merged yet. I
wanted to check if there’s anything else needed to move them forward.

Thanks,
Mahmoud

On Wed, May 7, 2025 at 6:35 PM Kito Cheng <kito.cheng@gmail.com> wrote:

> LGTM, thanks for the patch :)
>
> On Sun, Apr 27, 2025 at 7:59 PM <ma.mandourr@gmail.com> wrote:
> >
> > From: Mahmoud Abumandour <ma.mandourr@gmail.com>
> >
> > Add a code path for when source and dest are differently aligned.
> >
> > If misaligned access is slow or prohibited (i.e.
> `__riscv_misaligned_slow` or
> > `__riscv_misaligned_avoid` is defined), and the alignments of the source
> and destination are
> > different, we align the destination to do XLEN stores. This uses only one
> > aligned store for every four (or eight for XLEN == 64) bytes of data.
> >
> > This only affects the case where source and destination are differently
> aligned.
> > Previously, this case was handled by copying one byte at a time. The new
> > approach significantly reduces the number of executed (dynamic)
> instructions
> > (30% weighted average for `-mstrict-align`, while not affecting
> > `-mno-strict-align`, which is expected).
> >
> > A comparison between the implementations with raw numbers is posted here:
> >
> https://docs.google.com/spreadsheets/d/1KDnfhYVFQYIXb23LjsgWFyWna4A_9mcRZRLm_u0zELE/edit?usp=sharing
> >
> > While at it, the function is generally improved to use `uintxlen_t` and
> > eliminate gotos and macros.
> >
> > Mahmoud Abumandour (3):
> >   RISC-V: memcpy() Use uintxlen_t for xlen-sized copy
> >   RISC-V: memcpy() Use inline functions instead of macros and gotos
> >   RISC-V: memcpy() align dest when misaligned access is prohibited
> >
> >  newlib/libc/machine/riscv/memcpy.c | 163 +++++++++++++++++++----------
> >  1 file changed, 109 insertions(+), 54 deletions(-)
> >
> > --
> > 2.43.0
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/newlib/attachments/20250526/e0bf3b5e/attachment.htm>


More information about the Newlib mailing list