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
prev parent 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).