[RFC,V4] Enable libmvec support for RISC-V

  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.

Thanks,
yulong

---
 sysdeps/riscv/configure                       |   4 +
 sysdeps/riscv/configure.ac                    |   4 +
 sysdeps/riscv/rvd/Makefile                    |   5 +
 sysdeps/riscv/rvd/Versions                    |   5 +
 sysdeps/riscv/rvd/bits/math-vector.h          |  29 ++++
 sysdeps/riscv/rvd/cos.c                       |  94 ++++++++++++
 sysdeps/riscv/rvd/math_private.h              |  42 ++++++
 sysdeps/riscv/rvd/v_math.h                    | 139 ++++++++++++++++++
 sysdeps/riscv/rvd/vecmath_config.h            |  33 +++++
 sysdeps/unix/sysv/linux/riscv/libmvec.abilist |   1 +
 10 files changed, 356 insertions(+)
 mode change 100644 => 100755 sysdeps/riscv/configure
 create mode 100644 sysdeps/riscv/rvd/Makefile
 create mode 100644 sysdeps/riscv/rvd/Versions
 create mode 100644 sysdeps/riscv/rvd/bits/math-vector.h
 create mode 100644 sysdeps/riscv/rvd/cos.c
 create mode 100644 sysdeps/riscv/rvd/math_private.h
 create mode 100644 sysdeps/riscv/rvd/v_math.h
 create mode 100644 sysdeps/riscv/rvd/vecmath_config.h
 create mode 100644 sysdeps/unix/sysv/linux/riscv/libmvec.abilist
  

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.

jeff
  

在 2024/4/25 13:07, Jeff Law 写道:
>
>
> 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.
>
> jeff
Thanks Jeff for your advice, I'm working on a new implementation after 
reading the above code.
  

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
  

在 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
  

Hi yulong,  do you have any further progress? I finish a new version 
libmvec support for risc-v, which also base on implementations by 
Palmer's team over at Rivos.

     https://github.com/rivosinc/veclibm/

I can't find the vector function name mangling of risc-v, so I define it 
as follows, maybe it's incorrect, but I think it's worhting discussing.

     _ZGV<x>N<y>v<v...>_<func_name>

     'x' is the LMUL, if the LMUL is 1/2/4/8 and 'x' is 1/2/4/8.

     'y' is the count of elements also 'simdlen' in gcc.

     'v..' depends on the number of parameter, there are as many 'v' 
characters as there are parameters.

     'func_name' is the scalar function name.

This path have supported vectorized version for the following math 
function in risc-v (although now only support VLENB <= 256,  it's very 
easy to extend to larger VLENB). Besides, I also finish the gcc patch to 
support libmvec in risc-v.

exp/asin/atan/acos/atanh/exp10/exp2/tan/tanh/pow/sin/log/cos/acosh/asinh/atan2/expm1/tgamma/lgamma/log2/log10/cbrt/erfc/erf/cosh/sinh

Hi Palmer, I  temporarily change the Copyright information in some files 
which come from veclibm, it's not a viaolation of your Copyright, 
actually I don't know how to solve the conflict between LGPL and 
Apache2.0.  If you know, please tell me to fix it, thank you.

Zhijin Zeng


在 2024/5/10 21:06, yulong 写道:
>
> 在 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

This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 
 
本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。
From 0eda8e538c7f7d4036d9decceb714acf3314f885 Mon Sep 17 00:00:00 2001
From: Zhijin Zeng <zhijin.zeng@spacemit.com>
Date: Thu, 31 Oct 2024 18:13:19 +0800
Subject: [PATCH] RISC-V: support vector math library for risc-v

Add risc-v vector function mangling rules as follow:

_ZGV<x>N<y>v_<func_name>

'x' is the LMUL, if the LMUL is 1/2/4/8 and 'x' is 1/2/4/8.
'y' is the count of elements also 'simdlen' in gcc.
'func_name' is the scalar function name.

gcc/ChangeLog:

	* config/riscv/riscv.cc (INCLUDE_STRING):
	(riscv_vector_type_p):
	(supported_simd_type):
	(lane_size):
	(riscv_simd_clone_compute_vecsize_and_simdlen):
	(riscv_simd_clone_adjust):
	(riscv_simd_clone_usable):
	(TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN):
	(TARGET_SIMD_CLONE_ADJUST):
	(TARGET_SIMD_CLONE_USABLE):
---
 gcc/config/riscv/riscv.cc | 241 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 240 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 4f8e3ab931a..9b44d36b171 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 #define IN_TARGET_CODE 1
 
 #define INCLUDE_STRING
+#include <cmath>
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -33,6 +34,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "insn-config.h"
 #include "insn-attr.h"
 #include "recog.h"
+#include "cgraph.h"
 #include "output.h"
 #include "alias.h"
 #include "tree.h"
@@ -5197,7 +5199,9 @@ riscv_vector_type_p (const_tree type)
 {
   /* Currently, only builtin scalabler vector type is allowed, in the future,
      more vector types may be allowed, such as GNU vector type, etc.  */
-  return riscv_vector::builtin_type_p (type);
+  if (!type)
+    return false;
+  return riscv_vector::builtin_type_p (type) || VECTOR_TYPE_P (type);
 }
 
 static unsigned int
@@ -11099,6 +11103,231 @@ riscv_get_raw_result_mode (int regno)
   return default_get_reg_raw_mode (regno);
 }
 
+/* Return true for types that could be supported as SIMD return or
+   argument types.  */
+
+static bool
+supported_simd_type (tree t)
+{
+  if (SCALAR_FLOAT_TYPE_P (t) || INTEGRAL_TYPE_P (t))
+    {
+      HOST_WIDE_INT s = tree_to_shwi (TYPE_SIZE_UNIT (t));
+      return s == 1 || s == 2 || s == 4 || s == 8;
+    }
+  return false;
+}
+
+static unsigned
+lane_size (cgraph_simd_clone_arg_type clone_arg_type, tree type)
+{
+  gcc_assert (clone_arg_type != SIMD_CLONE_ARG_TYPE_MASK);
+
+  if (INTEGRAL_TYPE_P (type)
+      || SCALAR_FLOAT_TYPE_P (type))
+    switch (TYPE_PRECISION (type) / BITS_PER_UNIT)
+      {
+      default:
+	break;
+      case 1:
+      case 2:
+      case 4:
+      case 8:
+	return TYPE_PRECISION (type);
+      }
+  gcc_unreachable ();
+}
+
+/* Implement TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN.  */
+
+static int
+riscv_simd_clone_compute_vecsize_and_simdlen (struct cgraph_node *node,
+					struct cgraph_simd_clone *clonei,
+					tree base_type ATTRIBUTE_UNUSED,
+					int num, bool explicit_p)
+{
+  tree t, ret_type;
+  unsigned int elt_bit = 0;
+  unsigned HOST_WIDE_INT const_simdlen;
+
+  if (!TARGET_VECTOR)
+    return 0;
+
+  if (maybe_ne (clonei->simdlen, 0U)
+      && clonei->simdlen.is_constant (&const_simdlen)
+      && (const_simdlen < 2
+	  || const_simdlen > 1024
+	  || (const_simdlen & (const_simdlen - 1)) != 0))
+    {
+      if (explicit_p)
+	warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		    "unsupported simdlen %wd", const_simdlen);
+      return 0;
+    }
+
+  ret_type = TREE_TYPE (TREE_TYPE (node->decl));
+  if (TREE_CODE (ret_type) != VOID_TYPE
+      && !supported_simd_type (ret_type))
+    {
+      if (!explicit_p)
+	;
+      else if (COMPLEX_FLOAT_TYPE_P (ret_type))
+	warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		    "GCC does not currently support return type %qT "
+		    "for simd", ret_type);
+      else
+	warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		    "unsupported return type %qT for simd",
+		    ret_type);
+      return 0;
+    }
+
+  auto_vec<std::pair <tree, unsigned int>> vec_elts (clonei->nargs + 1);
+  if (TREE_CODE (ret_type) != VOID_TYPE)
+    {
+      elt_bit = lane_size (SIMD_CLONE_ARG_TYPE_VECTOR, ret_type);
+      vec_elts.safe_push (std::make_pair (ret_type, elt_bit));
+    }
+
+  int i;
+  tree type_arg_types = TYPE_ARG_TYPES (TREE_TYPE (node->decl));
+  bool decl_arg_p = (node->definition || type_arg_types == NULL_TREE);
+  for (t = (decl_arg_p ? DECL_ARGUMENTS (node->decl) : type_arg_types), i = 0;
+       t && t != void_list_node; t = TREE_CHAIN (t), i++)
+    {
+      tree arg_type = decl_arg_p ? TREE_TYPE (t) : TREE_VALUE (t);
+      if (clonei->args[i].arg_type != SIMD_CLONE_ARG_TYPE_UNIFORM
+	  && !supported_simd_type (arg_type))
+	{
+	  if (!explicit_p)
+	    ;
+	  else if (COMPLEX_FLOAT_TYPE_P (ret_type))
+	    warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+			"GCC does not currently support argument type %qT "
+			"for simd", arg_type);
+	  else
+	    warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+			"unsupported argument type %qT for simd",
+			arg_type);
+	  return 0;
+	}
+      unsigned lane_bits = lane_size (clonei->args[i].arg_type, arg_type);
+      if (clonei->args[i].arg_type == SIMD_CLONE_ARG_TYPE_VECTOR)
+	vec_elts.safe_push (std::make_pair (arg_type, lane_bits));
+      if (!elt_bit)
+	elt_bit = lane_bits;
+      if (elt_bit != lane_bits)
+	return 0;
+    }
+
+  if (!elt_bit)
+    return 0;
+
+  clonei->vecsize_mangle = 'n';
+  clonei->mask_mode = VOIDmode;
+  poly_uint64 simdlen;
+  auto_vec<poly_uint64> simdlens (2);
+
+  clonei->vecsize_int = 0;
+  clonei->vecsize_float = 0;
+
+  if ((unsigned int)TARGET_MIN_VLEN <= elt_bit)
+    return 0;
+
+  /* Keep track of the possible simdlens the clones of this function can have,
+     and check them later to see if we support them.  */
+  if (known_eq (clonei->simdlen, 0U))
+    {
+      if (TARGET_MAX_LMUL >= RVV_M1)
+	simdlens.safe_push (
+	    exact_div (poly_uint64 (TARGET_MIN_VLEN * RVV_M1), elt_bit));
+      if (TARGET_MAX_LMUL >= RVV_M2)
+	simdlens.safe_push (
+	    exact_div (poly_uint64 (TARGET_MIN_VLEN * RVV_M2), elt_bit));
+      if (TARGET_MAX_LMUL >= RVV_M4)
+	simdlens.safe_push (
+	    exact_div (poly_uint64 (TARGET_MIN_VLEN * RVV_M4), elt_bit));
+      if (TARGET_MAX_LMUL >= RVV_M8)
+	simdlens.safe_push (
+	    exact_div (poly_uint64 (TARGET_MIN_VLEN * RVV_M8), elt_bit));
+    }
+  else
+    simdlens.safe_push (clonei->simdlen);
+
+  unsigned j = 0;
+  while (j < simdlens.length ())
+    {
+      bool remove_simdlen = false;
+      for (auto elt : vec_elts)
+	if (known_gt (simdlens[j] * elt.second,
+	    TARGET_MIN_VLEN * TARGET_MAX_LMUL))
+	  {
+	    /* Don't issue a warning for every simdclone when there is no
+	       specific simdlen clause.  */
+	    if (explicit_p && maybe_ne (clonei->simdlen, 0U))
+	      warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+			  "GCC does not currently support simdlen %wd for "
+			  "type %qT",
+			  constant_lower_bound (simdlens[j]), elt.first);
+	    remove_simdlen = true;
+	    break;
+	  }
+      if (remove_simdlen)
+	simdlens.ordered_remove (j);
+      else
+	j++;
+    }
+
+  int count = simdlens.length ();
+  if (count == 0)
+    {
+      if (explicit_p && known_eq (clonei->simdlen, 0U))
+	{
+	  /* Warn the user if we can't generate any simdclone.  */
+	  //simdlen = exact_div (TARGET_MIN_VLEN * LMUL, elt_bit);
+	  warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+		      "GCC does not currently support a simdclone with simdlens"
+		      " %wd and %wd for these types.",
+		      constant_lower_bound (simdlen),
+		      constant_lower_bound (simdlen*2));
+	}
+      return 0;
+    }
+
+  gcc_assert (num < count);
+  clonei->vecsize_mangle = std::exp2 (num) + '0';
+  clonei->simdlen = simdlens[num];
+  return count;
+}
+
+/* Implement TARGET_SIMD_CLONE_ADJUST.  */
+
+static void
+riscv_simd_clone_adjust (struct cgraph_node *node)
+{
+  tree t = TREE_TYPE (node->decl);
+  TYPE_ATTRIBUTES (t) = make_attribute ("riscv_vector_cc", "default",
+					TYPE_ATTRIBUTES (t));
+}
+
+/* Implement TARGET_SIMD_CLONE_USABLE.  */
+
+static int
+riscv_simd_clone_usable (struct cgraph_node *node)
+{
+  switch (node->simdclone->vecsize_mangle)
+    {
+    case '1':
+    case '2':
+    case '4':
+    case '8':
+      if (!TARGET_VECTOR)
+	return -1;
+      return 0;
+    default:
+      gcc_unreachable ();
+    }
+}
+
 /* Initialize the GCC target structure.  */
 #undef TARGET_ASM_ALIGNED_HI_OP
 #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
@@ -11451,6 +11680,16 @@ riscv_get_raw_result_mode (int regno)
 #undef TARGET_GET_RAW_RESULT_MODE
 #define TARGET_GET_RAW_RESULT_MODE riscv_get_raw_result_mode
 
+#undef TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN
+#define TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN \
+  riscv_simd_clone_compute_vecsize_and_simdlen
+
+#undef TARGET_SIMD_CLONE_ADJUST
+#define TARGET_SIMD_CLONE_ADJUST riscv_simd_clone_adjust
+
+#undef TARGET_SIMD_CLONE_USABLE
+#define TARGET_SIMD_CLONE_USABLE riscv_simd_clone_usable
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-riscv.h"
  

Hi, Zhijin Zeng:
Thank you for your contribution.

I am still working on the relevant work, but not pushed it to upstream. 
Because there is an urgent project being done recently. After that, I 
will send patch to upstream as soon as possible.

Thanks!

yulong

在 2024/11/4 12:41, Zhijin Zeng 写道:
> Hi yulong,  do you have any further progress? I finish a new version
> libmvec support for risc-v, which also base on implementations by
> Palmer's team over at Rivos.
>
>       https://github.com/rivosinc/veclibm/
>
> I can't find the vector function name mangling of risc-v, so I define it
> as follows, maybe it's incorrect, but I think it's worhting discussing.
>
>       _ZGV<x>N<y>v<v...>_<func_name>
>
>       'x' is the LMUL, if the LMUL is 1/2/4/8 and 'x' is 1/2/4/8.
>
>       'y' is the count of elements also 'simdlen' in gcc.
>
>       'v..' depends on the number of parameter, there are as many 'v'
> characters as there are parameters.
>
>       'func_name' is the scalar function name.
>
> This path have supported vectorized version for the following math
> function in risc-v (although now only support VLENB <= 256,  it's very
> easy to extend to larger VLENB). Besides, I also finish the gcc patch to
> support libmvec in risc-v.
>
> exp/asin/atan/acos/atanh/exp10/exp2/tan/tanh/pow/sin/log/cos/acosh/asinh/atan2/expm1/tgamma/lgamma/log2/log10/cbrt/erfc/erf/cosh/sinh
>
> Hi Palmer, I  temporarily change the Copyright information in some files
> which come from veclibm, it's not a viaolation of your Copyright,
> actually I don't know how to solve the conflict between LGPL and
> Apache2.0.  If you know, please tell me to fix it, thank you.
>
> Zhijin Zeng
>
>
> 在 2024/5/10 21:06, yulong 写道:
>> 在 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
> This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking.
>   
> 本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。