Add Vector-Length-Specific RISC-V Vector extension support using generic backend#2593
Add Vector-Length-Specific RISC-V Vector extension support using generic backend#2593lemire merged 1 commit intosimdjson:masterfrom
Conversation
|
@camel-cdr This looks amazing. |
c074be4 to
ebbf345
Compare
|
I'm not sure why the workflows are failing, it worked locally and on hardware, I'll look at them tomorrow. |
305e10e to
912c9eb
Compare
|
Running tests again |
|
It seems that at least libyyjson.a was compiled for x64. If the problem is limited to this one library, we can skip it. But maybe this reflect another issue. |
d309254 to
c30d272
Compare
|
@lemire All tests are passing on CI as well now. I needed to disable |
| if(CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL x86_64 OR CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL amd64) | ||
| if((CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL x86_64 OR CMAKE_HOST_SYSTEM_PROCESSOR STREQUAL amd64) AND NOT DEFINED CMAKE_CROSSCOMPILING_EMULATOR) | ||
| add_test( | ||
| NAME simdjson_force_implementation_error |
|
@camel-cdr It is not a requirement, but have you considered add a little bit of documentation... maybe there: https://github.com/simdjson/simdjson/blob/master/doc/implementation-selection.md and possibly here: https://github.com/simdjson/simdjson/blob/master/HACKING.md This is optional and can be done as future PR. I think your work is a big deal, so maybe it is worth documenting. |
lemire
left a comment
There was a problem hiding this comment.
I think we can merge this, it looks excellent, but I will wait to see if @camel-cdr is interested in adding some words of documentation regarding RISC-V support. (optionally)
|
Yeah, I'll write an explanation |
|
@camel-cdr I'll merge this now, and I invite you to produce a pull request with some documentation regarding this work you did. |
This PR adds a new "rvv_vls" backend, which uses the RISC-V Vector extension.
It supports VLEN=128, VLEN=256 and VLEN=512, but requires globally compiling for the exact vector length of the hardware.
This works by setting adding
-march=rv64gcv_zvl<VLEN>b -mrvv-vector-bits=zvlto theCXXFLAGS.Due to limitations in current toolchains runtime dispatch isn't possible if there is only one translation unit, as is the case in the amalgamate.
I expect there will be a compiler switch in the future to make the codegen for the fixed length RVV binary compatible with larger VLENs (only using the lower part of the vector registers), but this isn't currently supported.
The plan is to later add a fully scalable Vector-Length-Agnostic "rvv" backend with proper runtime dispatch.
This requires writing entirely new backend without using the existing generic infrastructure, so it will take more work to do. (It's on the list of projects I'm currently working on)
Benchmark on the SpacemiT-X60, rvv-vls variant compiled with clang-19 and
-march=rv64gcv_zba_zbb_zbs_zbc_zicond_zvl256b -mrvv-vector-bits=zvl: