在 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 <shiyulong@iscas.ac.cn>
>>>
>>> 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 <ptpt@rivosinc.com> 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