From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cstnet.cn (smtp21.cstnet.cn [159.226.251.21]) by sourceware.org (Postfix) with ESMTPS id E024938460B2 for ; Fri, 10 May 2024 13:06:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E024938460B2 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=iscas.ac.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E024938460B2 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=159.226.251.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715346388; cv=none; b=FCkuv6MHOUAmI5dkptBTDPu49DEjcZ+hfgiwgqi/pFPB0qOz0Ro6FBd+HOzvVFBtymbVTZyF0nMIL9OyqxEOYvNRRZsFwGlwiTmyi35sBjrB+ZUkB08Sqc2QQ5nkGfa0s1GU5nNNrv28bgvlw8stlp6bgzXTgLQ1Xx4pS9kuAVE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715346388; c=relaxed/simple; bh=29g1kyTarpC9wcXyz9bf2dMRk0lEnkKDhR3P6FKqXl4=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=jxZ2aHU7QD0yO1t+8uIKytqb9y7ny8UJCJtyMHuFPOzopE+KAkrqJwVA8WxCSJfdnqMhDAtlMdYqkPpZul6uKzwMH7pHGo8nKgOTrhromrs0qtX+TTxoyPSfwpDIcCB2C+Jgnc+oV0ezPOp4RHcS7Yl04GVgKgdsDrhHuiBJXqM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.102] (unknown [49.82.90.81]) by APP-01 (Coremail) with SMTP id qwCowADX3RnCGz5mBsMXBA--.2689S3; Fri, 10 May 2024 21:06:12 +0800 (CST) Content-Type: multipart/alternative; boundary="------------n3vPymmNlsx89KiuNd0bEogK" Message-ID: Date: Fri, 10 May 2024 21:06:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC V4] Enable libmvec support for RISC-V To: Palmer Dabbelt , jeffreyalaw@gmail.com Cc: libc-alpha@sourceware.org, Darius Rad , Andrew Waterman , maskray@google.com, kito.cheng@sifive.com, wuwei2016@iscas.ac.cn, jiawei@iscas.ac.cn, shihua@iscas.ac.cn, chenyixuan@iscas.ac.cn References: From: yulong In-Reply-To: X-CM-TRANSID:qwCowADX3RnCGz5mBsMXBA--.2689S3 X-Coremail-Antispam: 1UD129KBjvJXoWxur1xZr17uFWxtFWUCrWrGrg_yoW5urW8pF 4rKrnIyrs7JayIg3WxZw47XF1Sk34rJrZ8Arn5K3yqvw45CF9rXrW8trWY9FZI9ry8Wryj vr1j9r98A3Z8ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkv14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1I6r4UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E 87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c0EjI I2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2IY04v7Mx8GjcxK6IxK0xIIj40E5I8C rwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r 106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij 64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr 0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF 0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUtkuxUUUUU= X-Originating-IP: [49.82.90.81] X-CM-SenderInfo: 5vkl53porqwq5lvft2wodfhubq/ X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------n3vPymmNlsx89KiuNd0bEogK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2024/5/1 0:26, Palmer Dabbelt 写道: > On Wed, 24 Apr 2024 22:07:31 PDT (-0700), jeffreyalaw@gmail.com wrote: >> >> >> On 4/15/24 1:21 AM, shiyulong@iscas.ac.cn wrote: >>> From: yulong >>> >>> Diff: Chande the version from GLIBC_2.39 to GLIBC_2.40. >>> This patch tries to enable libmvec on RISC-V. I also have demonstrated >>> how this all fits together by adding implementations for vector cos. >>> This patch is a try and we hope to receive valuable comments. >> Just an FYI -- Palmer's team over at Rivos have implementations for a >> number of routines that would fit into libmvec.  You might reach out to >> Ping Tak Peter Tang for information in his >> implementation. >> >>> https://github.com/rivosinc/veclibm/ >> >> >> THeir implementations may provide good guidance on performant >> implementations of various routines that libmvec typically provides. > > Ya, that's the idea of veclibm.  The actual functions are written in a > way that's more suitable for some other libraries, but the core > computational implemenations should be the same.  A few of us had > briefly talked internally about getting these into glibc, IIUC all the > code was written at Rivos and thus could be copyright assigned to the > FSF and used in glibc.  We don't have time to do that right now, but > if you're interested in helping that'd be awesome.  We'll need to be > careful with the copyright/licensing, though. Thanks for your reply.   I also received an email from Peter Tang. I am very interested in contributing to glibc. > > That said, I've never really quite managed to figure out how all the > libmvec stuff is supposed to fit together.  I'm more worried about the > ABI side of things than the implementation, so I think starting with > just one function to get the ABI template figure out is a reasonable > way to go and we can get the rest of the implementations ported over > next.  The first thing that jumps out on the ABI side of things is > cos() taking EMUL=2 types, I'm not sure if there's a reason for that > but it seems we'd want EMUL=1 to fit more data in the argument registers? Setting EMUL=2 is just a personal experiment. I think you are right and I will improve it in the next version. > > Also, I think some of this can be split out: the > roundtoint/converttoint isn't really a libmvec thing (see > https://inbox.sourceware.org/libc-alpha/20220803174258.4235-1-palmer@rivosinc.com/, > which fails some test), and ptr_barrier() can probably be pulled out > to something generic as it's the same as arm64's version. > > I'm also only seeing draft versions of the vector intrinsics.  I know > we merged them into GCC and usually that means things are stable, but > we merged these pre-freeze (based on some assertions things wouldn't > change) and things have drifted around a bit it the spec.  I think > we're probably safe just depending on the types, if there's no frozen > version we should at least write down exactly which version we're > following though. We are currently developing based on the latest branches. Can we declare that we are following RVV 1.0? > > Also: are there GCC patches for these?  It'd be great to be able to > test things through the whole codegen stack so we can make sure it works. Unfortunately, there are no patches for GCC right now. This may be the direction of future work. > >> >> jeff --------------n3vPymmNlsx89KiuNd0bEogK--