Re: [RFC V4] Enable libmvec support for RISC-V

[Palmer Dabbelt <palmer@dabbelt.com>]

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.

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?

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.

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.

>
> jeff