From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 90894224D5 for ; Fri, 26 Sep 2025 13:22:22 +0200 (CEST) Received: (qmail 32639 invoked by uid 550); 26 Sep 2025 11:22:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 32518 invoked from network); 26 Sep 2025 11:22:17 -0000 Message-ID: <599d592b-6828-4088-80bd-e9df7429c8d0@isrc.iscas.ac.cn> Date: Fri, 26 Sep 2025 19:21:56 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: musl@lists.openwall.com, Markus Wichmann Cc: Yao Zi References: <20250925131557.8907-1-pincheng.plct@isrc.iscas.ac.cn> <20250925131557.8907-2-pincheng.plct@isrc.iscas.ac.cn> <35488ed2-3c30-4bc4-89ab-70f30dee9890@isrc.iscas.ac.cn> From: Pincheng Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:rQCowABHloBYd9ZoQlaZBg--.48956S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kr1xJrWUWw17Zry8ZFW5KFg_yoW8Aw18pF WfCayqkrWkK34IqF48Ars2yrW8Zw4fGa43JrnYga48Z398GF9FqFn8t3WYga47Cw1akw4a 93W0vryFya1UAFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyCb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Jr0_Gr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCY02Avz4vE14v_Gw4l42xK82IYc2Ij 64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x 8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE 2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42 xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF 7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07brtCcUUUUU= X-Originating-IP: [218.76.28.114] X-CM-SenderInfo: pslquxhhqjh1xofwqxxvufhxpvfd2hldfou0/ Subject: Re: [musl] [PATCH 1/1] riscv64: optimize memset implementation with vector extension 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