public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
To: Evan Green <evan@rivosinc.com>
Cc: libc-alpha@sourceware.org, vineetg@rivosinc.com,
	slewis@rivosinc.com, Florian Weimer <fweimer@redhat.com>,
	palmer@rivosinc.com, Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: [PATCH v13 7/7] riscv: Add and use alignment-ignorant memcpy
Date: Mon, 4 Mar 2024 15:30:51 -0300	[thread overview]
Message-ID: <d01c1761-feb8-41b9-a030-3db586432db3@linaro.org> (raw)
In-Reply-To: <87v864c49s.fsf@linux-m68k.org>



On 02/03/24 07:33, Andreas Schwab wrote:
> On Feb 27 2024, Evan Green wrote:
> 
>> For CPU implementations that can perform unaligned accesses with little
>> or no performance penalty, create a memcpy implementation that does not
>> bother aligning buffers. It will use a block of integer registers, a
>> single integer register, and fall back to bytewise copy for the
>> remainder.
> 
> How has that been tested?  It causes memory corruption.
> 

The memcpy optimization has multiple issues:

 1. The implementation is wrong: the chunk size calculation is wrong
 leading to invalid memory access.

 2. It adds ifunc supports as default, so --disable-multi-arch does
 not work as expected for riscv.

 3. It mixes Linux files (memcpy ifunc selection which requires the
 vDSO/syscall mechanism) with generic support (the memcpy
 optimization itself).

 4. There is no __libc_ifunc_impl_list, which makes testing only
 check the selected implementation instead of all supported
 by the system.

The 2., 3., and 4. are not really a problem since they came most likely
from code base inexperience. However, the 1. is *really* a red
flag since it means that you did not run a 'make check' to certify
no regressions were found.

I could trigger the same failures on qemu-system/qemu-user by forcing the 
implementation to be used as default, even if your hardware does have 
RISCV_HWPROBE_MISALIGNED_FAST, you could also check for correctness.

I sent a newer version that [1] should fix all the issues I have found. 
The C implementation is also easier to follow and it should generate 
code as good as the assembly version, so please check if on real 
hardware (I have only tested on qemu). As per the previous discussion,
I would like to use this as a base for a generic implementation; to 
avoid each architecture to reimplement the same code (as I did for some 
string implementations).

[1] https://patchwork.sourceware.org/project/glibc/patch/20240304175902.1479562-1-adhemerval.zanella@linaro.org/

  reply	other threads:[~2024-03-04 18:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 22:56 [PATCH v13 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Evan Green
2024-02-27 22:56 ` [PATCH v13 1/7] riscv: Add Linux hwprobe syscall support Evan Green
2024-02-27 22:56 ` [PATCH v13 2/7] linux: Introduce INTERNAL_VSYSCALL Evan Green
2024-02-27 22:56 ` [PATCH v13 3/7] riscv: Add hwprobe vdso call support Evan Green
2024-02-27 22:56 ` [PATCH v13 4/7] riscv: Add __riscv_hwprobe pointer to ifunc calls Evan Green
2024-02-27 22:56 ` [PATCH v13 5/7] riscv: Enable multi-arg ifunc resolvers Evan Green
2024-02-27 22:56 ` [PATCH v13 6/7] riscv: Add ifunc helper method to hwprobe.h Evan Green
2024-02-27 22:56 ` [PATCH v13 7/7] riscv: Add and use alignment-ignorant memcpy Evan Green
2024-03-02 10:33   ` Andreas Schwab
2024-03-04 18:30     ` Adhemerval Zanella Netto [this message]
2024-03-04 19:35       ` Evan Green
2024-03-02 13:52   ` Andreas Schwab
2024-03-01 15:19 ` [PATCH v13 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d01c1761-feb8-41b9-a030-3db586432db3@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=evan@rivosinc.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=palmer@rivosinc.com \
    --cc=schwab@linux-m68k.org \
    --cc=slewis@rivosinc.com \
    --cc=vineetg@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).