On risc-v branch meet some errors

[sz-ok]

hi friends，
I do my work on risc-v branch，but meet some errors:

symm_lcopy_rvv_v1.c:38:#define VID_V_INT   vid_v_i32m2
symm_lcopy_rvv_v1.c:51:#define VID_V_INT   vid_v_i64m2
trmm_lncopy_rvv_v1.c:40:#define VID_V_UINT vid_v_i32m2
symm_ucopy_rvv_v1.c:38:#define VID_V_INT   vid_v_i32m2
symm_ucopy_rvv_v1.c:51:#define VID_V_INT   vid_v_i64m2

But in https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/master/auto-generated/intrinsic_funcs.md has no vid_v_i32m2 function and only vid_v_u32m2

by the way, in kernel/riscv64/trmm_lncopy_rvv_v1.c
the macro naming is confusing

#define VID_V_UINT vid_v_i32m2  ------> vid_v_u32m2
#define VMSGTU_VX_UINT vmsgt_vx_i32m2_b16   ------> vmsgtu_vx_u32m2_b16
#define VMSEQ_VX_UINT vmseq_vx_i32m2_b16  ------> vmseq_vx_u32m2_b16  

thanks

[brada4]

The by the way you need to present compiler version where it fails.

#ifndef vid_v_i32m2
#define vid_v_i32m2 vid_v_u32m2
#endif

[xianyi]

Is the intrinsic API frozen?

[sz-ok]

Is the intrinsic API frozen?

I heared it's almost done

[sz-ok]

The by the way you need to present compiler version where it fails.

#ifndef vid_v_i32m2
#define vid_v_i32m2 vid_v_u32m2
#endif

thanks for help，I should wait till API frozen

[ken-unger]

What version of clang are you using @sz-ok ? Using clang 16 I don't see an issue with compilation. I haven't gone back in time but we had previously been using clang 14 as well.

Point taken on the confusing macro usage. We'll fix in a future PR. Heller has done some additional optimizations for C/Z BLAS level 3 and he'll submit a new PR for that work in the near future.

[HellerZheng]

Typos are fixed together with PR 3893
For system don't support signed integer (vector index), I think could try alternative way.
That is change signed integer comparison to unsigned integer comparison
offset > (0 - vindex)
===> (offset + vindex) > 0
===> (offset + vindex + |offset|) > |offset|

diff --git a/kernel/riscv64/symm_lcopy_rvv_v1.c b/kernel/riscv64/symm_lcopy_rvv_v1.c
index f0def961..31ec266e 100644
--- a/kernel/riscv64/symm_lcopy_rvv_v1.c
+++ b/kernel/riscv64/symm_lcopy_rvv_v1.c
@@ -34,10 +34,10 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define VLEV_FLOAT vle32_v_f32m2
 #define VSEV_FLOAT vse32_v_f32m2
 #define VLSEV_FLOAT vlse32_v_f32m2
-#define INT_V_T     vint32m2_t
-#define VID_V_INT   vid_v_i32m2
-#define VADD_VX_INT vadd_vx_i32m2
-#define VMSGT_VX_INT vmsgt_vx_i32m2_b16
+#define UINT_V_T     vuint32m2_t
+#define VID_V_UINT   vid_v_u32m2
+#define VADD_VX_UINT vadd_vx_u32m2
+#define VMSGTU_VX_UINT vmsgtu_vx_u32m2_b16
 #define VBOOL_T     vbool16_t
 #define VMERGE_VVM_FLOAT  vmerge_vvm_f32m2
 #else
@@ -47,10 +47,10 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define VLEV_FLOAT vle64_v_f64m2
 #define VSEV_FLOAT vse64_v_f64m2
 #define VLSEV_FLOAT vlse64_v_f64m2
-#define INT_V_T     vint64m2_t
-#define VID_V_INT   vid_v_i64m2
-#define VADD_VX_INT vadd_vx_i64m2
-#define VMSGT_VX_INT vmsgt_vx_i64m2_b32
+#define UINT_V_T     vuint64m2_t
+#define VID_V_UINT   vid_v_u64m2
+#define VADD_VX_UINT vadd_vx_u64m2
+#define VMSGTU_VX_UINT vmsgtu_vx_u64m2_b32
 #define VBOOL_T     vbool32_t
 #define VMERGE_VVM_FLOAT  vmerge_vvm_f64m2
 #endif
@@ -60,6 +60,7 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLONG posY, FLOAT *b)
 {
     BLASLONG i, js, offset;
+    BLASLONG abs_offset, temp;
 
     FLOAT *ao1, *ao2;
 
@@ -67,10 +68,10 @@ int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLON
 
     FLOAT_V_T vb, va1, va2;
     VBOOL_T vbool;
-    INT_V_T vindex_max, vindex;
+    UINT_V_T vindex_max, vindex;
 
     size_t vl = VSETVL_MAX;
-    vindex_max   = VID_V_INT(vl);
+    vindex_max   = VID_V_UINT(vl);
 
     for (js = n; js > 0; js -= vl, posX += vl) {
         vl = VSETVL(js);
@@ -83,9 +84,12 @@ int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLON
             va2 = VLSEV_FLOAT(ao2, stride_lda, vl);
             va1 = VLEV_FLOAT(ao1, vl);
 
-            // offset > (0 - vindex)   --->   (offset + vindex) > 0
-            vindex = VADD_VX_INT(vindex_max, offset, vl);
-            vbool  = VMSGT_VX_INT(vindex, 0, vl);
+            abs_offset = labs(offset);
+            temp = offset + abs_offset; // then temp >= 0
+            // offset > (0 - vindex)   ===>   (offset + vindex) > 0
+            // ===> (offset + vindex + |offset|) > |offset|
+            vindex = VADD_VX_UINT(vindex_max, temp, vl);
+            vbool  = VMSGTU_VX_UINT(vindex, abs_offset, vl);
 
             vb =  VMERGE_VVM_FLOAT(vbool, va2, va1, vl);
             VSEV_FLOAT(b, vb, vl);

[sz-ok]

What version of clang are you using @sz-ok ? Using clang 16 I don't see an issue with compilation. I haven't gone back in time but we had previously been using clang 14 as well.

I am using gcc 10 (with rvv)，and it maybe according to the md：
https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/master/auto-generated/intrinsic_funcs.md

[sz-ok]

Typos are fixed together with PR 3893 For system don't support signed integer (vector index), I think could try alternative way. That is change signed integer comparison to unsigned integer comparison offset > (0 - vindex) ===> (offset + vindex) > 0 ===> (offset + vindex + |offset|) > |offset|

diff --git a/kernel/riscv64/symm_lcopy_rvv_v1.c b/kernel/riscv64/symm_lcopy_rvv_v1.c
index f0def961..31ec266e 100644
--- a/kernel/riscv64/symm_lcopy_rvv_v1.c
+++ b/kernel/riscv64/symm_lcopy_rvv_v1.c
@@ -34,10 +34,10 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define VLEV_FLOAT vle32_v_f32m2
 #define VSEV_FLOAT vse32_v_f32m2
 #define VLSEV_FLOAT vlse32_v_f32m2
-#define INT_V_T     vint32m2_t
-#define VID_V_INT   vid_v_i32m2
-#define VADD_VX_INT vadd_vx_i32m2
-#define VMSGT_VX_INT vmsgt_vx_i32m2_b16
+#define UINT_V_T     vuint32m2_t
+#define VID_V_UINT   vid_v_u32m2
+#define VADD_VX_UINT vadd_vx_u32m2
+#define VMSGTU_VX_UINT vmsgtu_vx_u32m2_b16
 #define VBOOL_T     vbool16_t
 #define VMERGE_VVM_FLOAT  vmerge_vvm_f32m2
 #else
@@ -47,10 +47,10 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define VLEV_FLOAT vle64_v_f64m2
 #define VSEV_FLOAT vse64_v_f64m2
 #define VLSEV_FLOAT vlse64_v_f64m2
-#define INT_V_T     vint64m2_t
-#define VID_V_INT   vid_v_i64m2
-#define VADD_VX_INT vadd_vx_i64m2
-#define VMSGT_VX_INT vmsgt_vx_i64m2_b32
+#define UINT_V_T     vuint64m2_t
+#define VID_V_UINT   vid_v_u64m2
+#define VADD_VX_UINT vadd_vx_u64m2
+#define VMSGTU_VX_UINT vmsgtu_vx_u64m2_b32
 #define VBOOL_T     vbool32_t
 #define VMERGE_VVM_FLOAT  vmerge_vvm_f64m2
 #endif
@@ -60,6 +60,7 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLONG posY, FLOAT *b)
 {
     BLASLONG i, js, offset;
+    BLASLONG abs_offset, temp;
 
     FLOAT *ao1, *ao2;
 
@@ -67,10 +68,10 @@ int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLON
 
     FLOAT_V_T vb, va1, va2;
     VBOOL_T vbool;
-    INT_V_T vindex_max, vindex;
+    UINT_V_T vindex_max, vindex;
 
     size_t vl = VSETVL_MAX;
-    vindex_max   = VID_V_INT(vl);
+    vindex_max   = VID_V_UINT(vl);
 
     for (js = n; js > 0; js -= vl, posX += vl) {
         vl = VSETVL(js);
@@ -83,9 +84,12 @@ int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLON
             va2 = VLSEV_FLOAT(ao2, stride_lda, vl);
             va1 = VLEV_FLOAT(ao1, vl);
 
-            // offset > (0 - vindex)   --->   (offset + vindex) > 0
-            vindex = VADD_VX_INT(vindex_max, offset, vl);
-            vbool  = VMSGT_VX_INT(vindex, 0, vl);
+            abs_offset = labs(offset);
+            temp = offset + abs_offset; // then temp >= 0
+            // offset > (0 - vindex)   ===>   (offset + vindex) > 0
+            // ===> (offset + vindex + |offset|) > |offset|
+            vindex = VADD_VX_UINT(vindex_max, temp, vl);
+            vbool  = VMSGTU_VX_UINT(vindex, abs_offset, vl);
 
             vb =  VMERGE_VVM_FLOAT(vbool, va2, va1, vl);
             VSEV_FLOAT(b, vb, vl);

Good work， thanks for your help

[sz-ok]

I used this way to avoid the above problems:

+++ b/kernel/riscv64/symm_lcopy_rvv_v1.c
@@ -35,7 +35,8 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define VSEV_FLOAT vse32_v_f32m2
 #define VLSEV_FLOAT vlse32_v_f32m2
 #define INT_V_T     vint32m2_t
-#define VID_V_INT   vid_v_i32m2
+#define VID_V_UINT   vid_v_u32m2
+#define VREINTERPRET_V_UINT_INT vreinterpret_v_u32m2_i32m2
 #define VADD_VX_INT vadd_vx_i32m2
 #define VMSGT_VX_INT vmsgt_vx_i32m2_b16
 #define VBOOL_T     vbool16_t
@@ -48,7 +49,8 @@ USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define VSEV_FLOAT vse64_v_f64m2
 #define VLSEV_FLOAT vlse64_v_f64m2
 #define INT_V_T     vint64m2_t
-#define VID_V_INT   vid_v_i64m2
+#define VID_V_UINT   vid_v_u64m2
+#define VREINTERPRET_V_UINT_INT vreinterpret_v_u64m2_i64m2
 #define VADD_VX_INT vadd_vx_i64m2
 #define VMSGT_VX_INT vmsgt_vx_i64m2_b32
 #define VBOOL_T     vbool32_t
@@ -70,7 +72,7 @@ int CNAME(BLASLONG m, BLASLONG n, FLOAT *a, BLASLONG lda, BLASLONG posX, BLASLON
     INT_V_T vindex_max, vindex;

     size_t vl = VSETVL_MAX;
-    vindex_max   = VID_V_INT(vl);
+    vindex_max   = VREINTERPRET_V_UINT_INT(VID_V_UINT(vl));

It worked also.

[martin-frbg]

The minutes of the RVV intrinsics working group meetings are available under https://github.com/riscv-admin/rvv-intrinsics/blob/main/meeting_minutes/ and there is a mailing list at https://lists.riscv.org/g/tech-rvv-intrinsics
From my reading of this, the 1.0 spec appears to be far from finalized, and there is/was a proposal to cull about 25 percent of the intrinsics present in the 0.10 draft. I was not aware that RISCV APIs are still that unstable, but I guess we have to live with that

[sz-ok]

The minutes of the RVV intrinsics working group meetings are available under https://github.com/riscv-admin/rvv-intrinsics/blob/main/meeting_minutes/ and there is a mailing list at https://lists.riscv.org/g/tech-rvv-intrinsics From my reading of this, the 1.0 spec appears to be far from finalized, and there is/was a proposal to cull about 25 percent of the intrinsics present in the 0.10 draft. I was not aware that RISCV APIs are still that unstable, but I guess we have to live with that

Fine，I will read it， thanks

[sz-ok]

I am going to close this issue as it has been resolved. The problem is RISCV APIs are still that unstable, I should pay a attention to this issue.

Regards

[sergei-lewis]

Note #3919 updates intrinsics to match latest spec