erasure_code: add prefetch and vsetvli optimization #351

lvshuo2016 · 2025-07-29T12:55:10Z

Add prefetch and vsetvli support, on some RV real hardware platforms, its performance can be improved by 100%.

pablodelara · 2025-07-29T14:43:12Z

configure.ac

 		if test "x$rvv" = "xyes"; then
-		  CFLAGS+=" -march=rv64gcv"
-		  CCASFLAGS+=" -march=rv64gcv"
+		  CFLAGS+=" -march=rv64gcv_zicbop"


It looks like this is going to be in conflict with CFLAGS+=" -march=rv64gcv_zbc_zvbc_zvbb" in https://github.com/intel/isa-l/pull/350/files.

They shouldn't conflict because they are on different branches.

I know, but what I meant is that the flags are different. Which one will stay? Or will it be a combination of both? I don't quite understand RISC-V flags

I do a simple compiler test, -march=rv64gcv_zicbop_zbc_zvbc_zvbb,the flags combine both. It compiler successfully.

It should include detection of zicbop at both compile time and runtime, rather than adding it directly.

pablodelara · 2025-07-31T10:58:38Z

Can you sign off the commit? Thanks!

lvshuo2016 · 2025-07-31T12:47:10Z

Can you sign off the commit? Thanks!

Updated. Thanks.

sunyuechi · 2025-07-31T15:22:47Z

Similarly, https://github.com/ChristopherHX/github-act-runner/ encountered a panic and is currently under investigation...

lvshuo2016 · 2025-08-08T03:18:21Z

do you have comments? If have i can fix it.

sunyuechi · 2025-08-08T10:29:13Z

configure.ac

 		if test "x$rvv" = "xyes"; then
-		  CFLAGS+=" -march=rv64gcv"
-		  CCASFLAGS+=" -march=rv64gcv"
+		  CFLAGS+=" -march=rv64gcv_zicbop"


It should include detection of zicbop at both compile time and runtime, rather than adding it directly.

sunyuechi · 2025-08-08T10:29:41Z

erasure_code/riscv64/gf_2vect_dot_prod_rvv.S


-    vsetvli a5, x0, e8, m1  /* Set vector length to maximum */
-
+    vsetvli a5, x0, e8, m1,ta,ma  /* Set vector length to maximum */


Please split the commits — the addition of ta and ma for vsetvli should be in a separate commit.

Why do ta and ma for vsetvli need to be committed separately?

The prefetch part and filling in the default ta and ma for vset are two unrelated matters, and they should generally not be combined in a single commit, as doing so makes the commit appear confusing.

Vsetvli is just a one-line modification, and the function is very clear. Is it necessary to make a separate commit?

The purpose of splitting is to make things simpler — as long as the functionalities are separate, this applies whether it’s a single line or a single word.
Such split commits are actually a necessary requirement in most open-source projects. However, for isa-l specifically, it might be better to let pablodelara decide. I don’t want to say it must be done in a certain way.

I agree with @sunyuechi, even if it is one line. And especially if it is only one line, it should be easy to split into two commits.

pablodelara · 2025-08-25T08:43:26Z

configure.ac

+					".insn i 0x0F, 0, x0, x0, 0x010" ::: "memory"
+				);
+			])],
+			[AC_DEFINE([HAVE_ZICBOP], [1], [Enable Zicbop instructions])


What are the differences in code path if this instruction is available or not?

It should add macro HAVE_ZICBOP judgment conditions in the code.

sunyuechi · 2025-08-26T02:19:06Z

Add prefetch and vsetvli support, on some RV real hardware platforms, its performance can be improved by 100%.

Specifically, which hardware is it?

sunyuechi · 2025-08-27T03:14:15Z

The commits need to be reorganized;

roughly three commits are needed: prefetch, vsetvli default value,
and implementation.

For example, this change and other unrelated logic changes should be moved out of the prefetch commit:

- slli t6, x_vec, 5
+ slli t6, x_vec, 2

The HAVE_ZICBOP macro should be merged into the prefetch commit.

lvshuo2016 · 2025-08-28T08:49:58Z

The commits need to be reorganized;

roughly three commits are needed: prefetch, vsetvli default value, and implementation.

For example, this change and other unrelated logic changes should be moved out of the prefetch commit:
- slli t6, x_vec, 5
+ slli t6, x_vec, 2
The HAVE_ZICBOP macro should be merged into the prefetch commit.

Updated.

lvshuo2016 · 2025-09-03T01:51:00Z

Could this PR be merged?

sunyuechi · 2025-09-03T12:58:08Z

configure.ac

+			[AC_DEFINE([HAVE_ZICBOP], [0], [Disable Zicbop instructions])
+			AM_CONDITIONAL([HAVE_ZICBOP], [false]) zicbop=no]
+		)
+		AC_MSG_RESULT([$zicbop])


This should belong to the third commit, but it's currently in the first commit.

It is currently in third commit. not in first commit.

It is currently in third commit. not in first commit.

+ AC_MSG_RESULT([$zicbop])

is in erasure_code: add optimization implementation, but I think it should be in erasure_code: add prefetch optimization.

It is currently in erasure_code: add prefetch optimization.

commit eac4d0f (HEAD -> riscv-optimize, origin/riscv-optimize)
Author: lvshuo [email protected]
Date: Thu Aug 28 16:48:04 2025 +0800

erasure_code: add prefetch optimaztion Signed-off-by: Shuo Lv <[email protected]>

diff --git a/configure.ac b/configure.ac
index 1a1476a..e89d660 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,6 +38,7 @@ AM_CONDITIONAL([CPU_PPC64LE], [test "$CPU" = "ppc64le"])
AM_CONDITIONAL([CPU_RISCV64], [test "$CPU" = "riscv64"])
AM_CONDITIONAL([CPU_UNDEFINED], [test "x$CPU" = "x"])
AM_CONDITIONAL([HAVE_RVV], [false])
+AM_CONDITIONAL([HAVE_ZICBOP], [false])

Check for programs

AC_PROG_CC_STDC
@@ -70,10 +71,28 @@ case "${CPU}" in
[AC_DEFINE([HAVE_RVV], [0], [Disable RVV instructions])
AM_CONDITIONAL([HAVE_RVV], [false]) rvv=no]
)

AC_MSG_CHECKING([Zicbop support])

AC_COMPILE_IFELSE(

[AC_LANG_PROGRAM([], [

__asm__ volatile(

".option arch, +zicbop\n"

".insn i 0x0F, 0, x0, x0, 0x010" ::: "memory"

);

])],

[AC_DEFINE([HAVE_ZICBOP], [1], [Enable Zicbop instructions])

AM_CONDITIONAL([HAVE_ZICBOP], [true]) zicbop=yes],

[AC_DEFINE([HAVE_ZICBOP], [0], [Disable Zicbop instructions])

AM_CONDITIONAL([HAVE_ZICBOP], [false]) zicbop=no]

) AC_MSG_RESULT([$zicbop])

It looks that the picture could not display here.

I used

gh pr checkout 351 git show bbbbf6c

and saw that it’s still in this commit.

It seems there is a problem, my local rebase has a conflict

sunyuechi · 2025-09-03T12:59:10Z

erasure_code/riscv64/gf_2vect_dot_prod_rvv.S


-    vsetvli a5, x0, e8, m1  /* Set vector length to maximum */
-
+    vsetvli a5, x0, e8, m1,ta,ma  /* Set vector length to maximum */


The newly added ta and ma in vset should use the same spacing as in the first half of the line.

sunyuechi · 2025-09-03T13:00:31Z

erasure_code/riscv64/gf_3vect_dot_prod_rvv.S

-    slli t_offset, x_vec, 5
+    slli x_vec, x_vec, 3
+
+    slli t_offset, x_vec, 2


The commit message should include the reason for changing the implementation.

lvshuo2016 · 2025-09-04T08:28:48Z

All is update.

sunyuechi · 2025-09-04T08:42:53Z

Add prefetch and vsetvli support, on some RV real hardware platforms, its performance can be improved by 100%.

Specifically, which hardware is it?

internal self-developed chip, but it has no effect on the current development board which is the sequentially launched core

Please try to explain the situation and/or describe the test environment in the commit message.

lvshuo2016 · 2025-09-05T07:00:59Z

All is updated.

lvshuo2016 · 2025-09-08T00:50:49Z

Could this PR be merged?

pablodelara · 2025-09-10T09:11:38Z

@sunyuechi what do you think of the latest code?

pablodelara · 2025-09-10T09:20:13Z

@lvshuo2016 one more comment. Could you review your commit messages? There are typos and also the "Signed-off-by" line should be at the end of message always.

pablodelara · 2025-09-10T11:36:01Z

erasure_code/riscv64/gf_4vect_dot_prod_rvv.S


-    vsetvli t0, x0, e8, m1  /* Set vector length to maximum */
-
+  #  vsetvli t0, x0, e8, m1  /* Set vector length to maximum */


Can this be removed?

sunyuechi · 2025-09-10T15:49:22Z

Add prefetch and vsetvli support, on some RV real hardware platforms, its performance can be improved by 100%.

Specifically, which hardware is it?

internal self-developed chip, but it has no effect on the current development board which is the sequentially launched core

Please try to explain the situation and/or describe the test environment in the commit message.

Please add the relevant description. Also, can we change the vsetvli commit subject to indicate adding default values instead? Since there’s no performance optimization involved.

sunyuechi · 2025-09-10T16:29:40Z

In "erasure_code: add prefetch optimization", a compile-time check was added, but a runtime check still needs to be implemented.

reduce one slli instructions and remove the dependence between vle8.v and ld instructions Signed-off-by: Shuo Lv <[email protected]>

lvshuo2016 · 2025-09-11T08:16:02Z

@lvshuo2016 one more comment. Could you review your commit messages? There are typos and also the "Signed-off-by" line should be at the end of message always.

Updated.

add vsetvli parameter to default values Signed-off-by: Shuo Lv <[email protected]>

lvshuo2016 · 2025-09-11T08:23:31Z

Add prefetch and vsetvli support, on some RV real hardware platforms, its performance can be improved by 100%.

Please try to explain the situation and/or describe the test environment in the commit message.

Please add the relevant description. Also, can we change the vsetvli commit subject to indicate adding default values instead? Since there’s no performance optimization involved.

Updated.

lvshuo2016 · 2025-09-11T08:27:39Z

runtime check

runtime check? Do you means getauxval check?

sunyuechi · 2025-09-11T08:32:23Z

getauxval or hwprobe, currently ec_riscv64_dispatcher.c only checks for v.

lvshuo2016 · 2025-09-14T03:30:24Z

prefetch

getauxval or hwprobe, currently ec_riscv64_dispatcher.c only checks for v.

We can use code like the following to check.
#ifndef DETECT_RISCV64_HWCAP_ISA_ZICACHEOP
#define DETECT_RISCV64_HWCAP_ISA_ZICACHEOP (1UL << 28)
#endif

int supports_riscv_prefetch() {
unsigned long hwcap = getauxval(AT_HWCAP);
if (hwcap & DETECT_RISCV64_HWCAP_ISA_ZICACHEOP) {
return 1; // support
}
return 0; // not support
}
in .S file,
call supports_riscv_prefetch to determine whether to execute prefetch. if It support then call prefetch, or else don't call.

Then call this C function in assembly. Of course, the check code can also be implemented in assembly, but there are too many instructions.
Performing runtime checks on each prefetch instruction will incur a lot of overhead. Prefetch is an extension instruction, but it is a basic function in most hardware, and there is not much need to add runtime checks for each Prefetch instruction separately.
If only exit simply by judging that prefetch is not supported, the result will be the same as if prefetch cannot be executed. What do you think?

sunyuechi · 2025-09-15T03:53:07Z

Then call this C function in assembly. Of course, the check code can also be implemented in assembly, but there are too many instructions. Performing runtime checks on each prefetch instruction will incur a lot of overhead. Prefetch is an extension instruction, but it is a basic function in most hardware, and there is not much need to add runtime checks for each Prefetch instruction separately. If only exit simply by judging that prefetch is not supported, the result will be the same as if prefetch cannot be executed. What do you think?

According to riscv64_multibinary.h, the selection of the corresponding function is only detected at the first run, not at every instruction execution, so the overhead should be minimal.

For the hwprobe implementation, you can refer to #350. From the email addresses, it looks like you’re from the same parent company, so perhaps you could increase collaboration.

lvshuo2016 · 2025-09-15T09:40:35Z

Then call this C function in assembly. Of course, the check code can also be implemented in assembly, but there are too many instructions. Performing runtime checks on each prefetch instruction will incur a lot of overhead. Prefetch is an extension instruction, but it is a basic function in most hardware, and there is not much need to add runtime checks for each Prefetch instruction separately. If only exit simply by judging that prefetch is not supported, the result will be the same as if prefetch cannot be executed. What do you think?

According to riscv64_multibinary.h, the selection of the corresponding function is only detected at the first run, not at every instruction execution, so the overhead should be minimal.

For the hwprobe implementation, you can refer to #350. From the email addresses, it looks like you’re from the same parent company, so perhaps you could increase collaboration.

hwprobe don't support runtime check for Zicacheop(prefetch) and there is no related macro in kernel head file which confirmed with 350 author yinlenree.

sunyuechi · 2025-09-15T10:15:51Z

Yes, at the moment there is only a patch series to add hwprobe support for Zicbop
(e.g. https://lkml.org/lkml/2025/9/11/849), but it has not yet been merged upstream.

If there is no clear benefit shown on publicly available hardware yet, it might be more
appropriate to wait until the kernel side has merged the corresponding hwprobe support
before moving forward with this optimization in ISA-L.

Or first add hwprobe support based on the related patch?

lvshuo2016 · 2025-09-15T11:36:21Z

Or first add hwprobe support based on the related patch?

Yes, at the moment there is only a patch series to add hwprobe support for Zicbop (e.g. https://lkml.org/lkml/2025/9/11/849), but it has not yet been merged upstream.

If there is no clear benefit shown on publicly available hardware yet, it might be more appropriate to wait until the kernel side has merged the corresponding hwprobe support before moving forward with this optimization in ISA-L.

Or first add hwprobe support based on the related patch?

It may not compile successfully in current kernel if add hwprobe support based on the related patch. So I will remove the prefetch patch first.

lvshuo2016 · 2025-09-17T02:22:10Z

Zicacheop

There are two ways. One is to add prefetch, which has no side effects and has added compile-time detection. The lack of dynamic detection here is not a very important issue. Later, when the kernel supports it, a patch can be also added. The other is to remove the prefetch patch submission. Which one do you think is suitable?

lvshuo2016 · 2025-09-17T09:30:46Z

@pablodelara hi, Pablo, what do you think? should we merge it or remove the prefetch patch ?

sunyuechi · 2025-09-17T10:55:49Z

I think it’s reasonable to either wait until hwprobe is merged before adding prefetch, or to first add prefetch behind a compile-time option (default off) as an experimental feature.

If it’s to be merged now, there are some adjustments needed:

Currently there are cases where the compiler supports it but the CPU does not, so it’s necessary to change the build to ensure prefetch is also disabled by default even if the compiler supports it.
Since there is no publicly available hardware for validation, the commit message for prefetch should include an explanation (how it was tested, what effect it has, and why prefetch is being added, Including an explanation of the current situation of this extension detection.).

pablodelara · 2025-09-17T22:42:25Z

I think it’s reasonable to either wait until hwprobe is merged before adding prefetch, or to first add prefetch behind a compile-time option (default off) as an experimental feature.

If it’s to be merged now, there are some adjustments needed:

Currently there are cases where the compiler supports it but the CPU does not, so it’s necessary to change the build to ensure prefetch is also disabled by default even if the compiler supports it.

Since there is no publicly available hardware for validation, the commit message for prefetch should include an explanation (how it was tested, what effect it has, and why prefetch is being added, Including an explanation of the current situation of this extension detection.).

When you say wait until hwprobe is merged, do you mean https://lkml.org/lkml/2025/9/11/849?
Being this an external dependency, it's going to make this tough...

sunyuechi · 2025-09-18T02:17:05Z

@pablodelara Yes, I’m okay with either merging quickly or waiting until hwprobe is merged — it mainly depends on how the author decides to adjust the patch.

pablodelara · 2025-09-18T14:50:56Z

@pablodelara Yes, I’m okay with either merging quickly or waiting until hwprobe is merged — it mainly depends on how the author decides to adjust the patch.

Up to you both. I'm OK merging it if you are OK with it, with the changes required.

lvshuo2016 · 2025-09-19T02:56:13Z

I think it’s reasonable to either wait until hwprobe is merged before adding prefetch, or to first add prefetch behind a compile-time option (default off) as an experimental feature.
If it’s to be merged now, there are some adjustments needed:

Currently there are cases where the compiler supports it but the CPU does not, so it’s necessary to change the build to ensure prefetch is also disabled by default even if the compiler supports it.

Since there is no publicly available hardware for validation, the commit message for prefetch should include an explanation (how it was tested, what effect it has, and why prefetch is being added, Including an explanation of the current situation of this extension detection.).

When you say wait until hwprobe is merged, do you mean https://lkml.org/lkml/2025/9/11/849? Being this an external dependency, it's going to make this tough...

I remove the prefetch patch,the current code could be merge. I will create a new pull request to track prefetch(include runtime check).

pablodelara reviewed Jul 29, 2025

View reviewed changes

lvshuo2016 force-pushed the riscv-optimize branch from 3b900a8 to 54339a6 Compare July 31, 2025 12:45

lvshuo2016 force-pushed the riscv-optimize branch from 54339a6 to 41fa113 Compare August 6, 2025 10:04

sunyuechi reviewed Aug 8, 2025

View reviewed changes

lvshuo2016 force-pushed the riscv-optimize branch from 41fa113 to 64e23f0 Compare August 12, 2025 03:00

lvshuo2016 force-pushed the riscv-optimize branch from 64e23f0 to 339b646 Compare August 24, 2025 08:43

pablodelara reviewed Aug 25, 2025

View reviewed changes

lvshuo2016 force-pushed the riscv-optimize branch 3 times, most recently from 87ab99c to be89c37 Compare August 28, 2025 08:38

sunyuechi reviewed Sep 3, 2025

View reviewed changes

lvshuo2016 force-pushed the riscv-optimize branch 2 times, most recently from 6a8fa6c to eac4d0f Compare September 4, 2025 08:27

lvshuo2016 force-pushed the riscv-optimize branch 3 times, most recently from 2f626d5 to 99d5360 Compare September 5, 2025 06:58

pablodelara closed this Sep 10, 2025

pablodelara reopened this Sep 10, 2025

pablodelara reviewed Sep 10, 2025

View reviewed changes

erasure_code: add optimization implementation

af4c19d

reduce one slli instructions and remove the dependence between vle8.v and ld instructions Signed-off-by: Shuo Lv <[email protected]>

lvshuo2016 force-pushed the riscv-optimize branch 2 times, most recently from e96d047 to aee9736 Compare September 11, 2025 08:07

erasure_code: set vsetvli to default parameter

2e5b5e1

add vsetvli parameter to default values Signed-off-by: Shuo Lv <[email protected]>

lvshuo2016 force-pushed the riscv-optimize branch from aee9736 to c4bbe99 Compare September 11, 2025 08:22

lvshuo2016 force-pushed the riscv-optimize branch from c4bbe99 to 2e5b5e1 Compare September 19, 2025 02:54


		vsetvli a5, x0, e8, m1 /* Set vector length to maximum */

		vsetvli a5, x0, e8, m1,ta,ma /* Set vector length to maximum */


		vsetvli t0, x0, e8, m1 /* Set vector length to maximum */

		# vsetvli t0, x0, e8, m1 /* Set vector length to maximum */

erasure_code: add prefetch and vsetvli optimization #351

Are you sure you want to change the base?

erasure_code: add prefetch and vsetvli optimization #351

Uh oh!

Conversation

lvshuo2016 commented Jul 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pablodelara commented Jul 31, 2025

Uh oh!

lvshuo2016 commented Jul 31, 2025

Uh oh!

sunyuechi commented Jul 31, 2025

Uh oh!

lvshuo2016 commented Aug 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lvshuo2016 Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sunyuechi commented Aug 26, 2025

Uh oh!

sunyuechi commented Aug 27, 2025

Uh oh!

lvshuo2016 commented Aug 28, 2025

Uh oh!

lvshuo2016 commented Sep 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Check for programs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lvshuo2016 Aug 11, 2025 •

edited

Loading

pablodelara commented Sep 10, 2025 •

edited

Loading

lvshuo2016 commented Sep 14, 2025 •

edited

Loading