mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Pincheng Wang <pincheng.plct@isrc.iscas.ac.cn>
To: musl@lists.openwall.com, Markus Wichmann <nullplan@gmx.net>
Cc: Yao Zi <ziyao@disroot.org>
Subject: Re: [musl] [PATCH 1/1] riscv64: optimize memset implementation with vector extension
Date: Fri, 26 Sep 2025 19:21:56 +0800	[thread overview]
Message-ID: <599d592b-6828-4088-80bd-e9df7429c8d0@isrc.iscas.ac.cn> (raw)
In-Reply-To: <aNYKh708fxqxrjGI@voyager>

On 2025/9/26 11:37, Markus Wichmann wrote:
> Am Fri, Sep 26, 2025 at 08:31:53AM +0800 schrieb Pincheng Wang:
>> I am investigating a runtime detection and dispatch mechanism to select the
>> appropriate implementation based on actual hardware support. If I make
>> progress on this and verify it works as expected, I will update the approach
>> in a v2 patch.
>>
> 
> There seems to be a hwcap flag for ISA_V that might be usable. Not sure
> if it is any help for memcpy() though, because memcpy() is a function
> GCC can insert calls to at any point, including the dynamic linker
> stages 1 and 2, and references to libc.hwcap are invalid there. The only
> solution I see is to explicitly switch to the optimized version after it
> is possible to do so and use the generic version for starters. But that
> would be a bit of a larger change to the code base.
> 
> Ciao,
> Markus

Hi, Markus

Thanks for your suggestion! I do plan to use hwcap to detect the V 
extension, similar to implementations on other platforms. Your point 
about hwcap being unavailable during the linker's bootstrap stage is 
indeed very helpful - I hadn't fully considered that. I'll look into 
adopting your suggestion: using a generic implementation initially and 
explicitly switching to the optimized version once hwcap becomes 
available. However, I can't yet be certain about the exact 
implementation details, as this will require some time for coding and 
testing.

Moreover, since I haven't found any existing RISC-V examples of such 
detection-and-dispatch mechanisms, and given that this approach would 
indeed entail significant changes to the dynamic linker, I plan to send 
the v2 patch as an RFC after I finish my current work.

Thank you again for your insightful comments and suggestions!

Best regards,
Pincheng Wang


      reply	other threads:[~2025-09-26 11:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-25 13:15 [musl] [PATCH 0/1] riscv64: Add RVV optimized memset implementation Pincheng Wang
2025-09-25 13:15 ` [musl] [PATCH 1/1] riscv64: optimize memset implementation with vector extension Pincheng Wang
2025-09-25 15:30   ` Yao Zi
2025-09-26  0:31     ` Pincheng Wang
2025-09-26  3:37       ` Markus Wichmann
2025-09-26 11:21         ` Pincheng Wang [this message]

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=599d592b-6828-4088-80bd-e9df7429c8d0@isrc.iscas.ac.cn \
    --to=pincheng.plct@isrc.iscas.ac.cn \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    --cc=ziyao@disroot.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).