Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building Error of OpenBLAS C910V Target #4029

Closed
luyanaa opened this issue Apr 30, 2023 · 13 comments · Fixed by #4090
Closed

Building Error of OpenBLAS C910V Target #4029

luyanaa opened this issue Apr 30, 2023 · 13 comments · Fixed by #4090

Comments

@luyanaa
Copy link

luyanaa commented Apr 30, 2023

When building OpenBLAS with T-head 2.6.1 toolchain, the following multiples errors are found.

error: incompatible types when assigning to type 'vfloat32m4_t' from type 'int'
   35 | #define VLSEV_FLOAT vlse_v_f32m4
      |                     ^~~~~~~~~~~~
note: in expansion of macro 'VLSEV_FLOAT'
  130 |                         vy = VLSEV_FLOAT(&y[iy], stride_y, gvl);
      |                              ^~~~~~~~~~~

error: incompatible types when assigning to type 'vfloat32m4_t' from type 'int'
   34 | #define VLEV_FLOAT vle_v_f32m4
      |                    ^~~~~~~~~~~
note: in expansion of macro 'VLEV_FLOAT'
  145 |                         vx = VLEV_FLOAT(&x[j], gvl);

Refer to #4024 for the build CI to test the problem.

@martin-frbg
Copy link
Collaborator

can you please try the riscv branch instead of develop ? unfortunately the rvv extension and intrinsics are still a bit unstable, the develop branch still uses the older rvv-0.7.1 syntax as far as I know, which may no longer be supported by newer toolchains

@RevySR
Copy link
Contributor

RevySR commented Apr 30, 2023

in risc-v branch

../kernel/riscv64/max_vector.c:62:31: error: incompatible types when assigning to type 'vfloat64m1_t' from type 'int'
62 | #define VFREDMAXVS_FLOAT JOIN(__riscv_vfredmax_vs_f, ELEN, LMUL, _f, JOIN2( ELEN, m1))

../kernel/riscv64/max_vector.c:61:30: error: incompatible types when assigning to type 'vfloat64m8_t' from type 'int'
61 | #define VLSEV_FLOAT JOIN(__riscv_vlse, ELEN, _v_f, ELEN, LMUL)

../kernel/riscv64/max_vector.c:65:30: error: incompatible types when assigning to type 'vfloat64m8_t' from type 'int'
65 | #define VFMVVF_FLOAT JOIN(__riscv_vfmv, _v_f_f, ELEN, LMUL, _)

@martin-frbg
Copy link
Collaborator

Too bad - there are currently no open PRs for RISCV issues, and I cannot suggest with any certainty which toolchain is currently expected to work but please see #3808

@martin-frbg
Copy link
Collaborator

That said, it could be that one currently still needs to use an old 1.x version of the t-head compiler for the develop branch, but the riscv branch may only compile with LLVM16

@martin-frbg
Copy link
Collaborator

martin-frbg commented May 7, 2023

So the max_vector.c in the risc-v branch compiles fine with (riscv-)llvm 16, but that same compiler stumbles on what appears to be old rvv-0.7 standard instructions in sgemm_kernel_16x4_c910v.c (Among them the vsetvli that is used in c_check to confirm that the compiler is capable of understanding RVV instructions, so a llvm-based build of the riscv
branch would default to the plain C riscv64_generic target at the moment. Also Makefile.riscv64 needs separate option sections for gcc and clang ).
The develop branch on the other hand was last brought to the 0.7 standard of the draft RVV specification, so indeed requires an equally old vendor toolchain from t-head (probably from around mid-2021) to compile.
Hopefully the risc-v branch can be consolidated and merged as soon as stable specifications for both vector instructions and vector intrinsics are released.

@zejianzhang1982
Copy link

i have build OpenBLAS-risc-v successfully; with Xuantie-900-gcc-linux-6.6.0-glibc-x86_64-V3.0.1, should add " #include <riscv_vector_v0p10_non_policy_common.h> " in common.h

@martin-frbg
Copy link
Collaborator

Thanks - did you build the current 0.3.28 (or the develop branch) ? I also wonder if this header can be included in all cases, or if it is specific to this version of the (cross-)compiler and might prevent anyone from compiling on the device itself.

@ztjjj9
Copy link

ztjjj9 commented Dec 5, 2024

@martin-frbg @zejianzhang1982
Hi!
I successfully compiled and installed OpenBLAS (0.3.28 develop branch) using the toolchain mentioned by @zejianzhang1982! I performed a simple correctness test on the K230 development board, and the results were correct! The command I used to compile OpenBLAS was:
"make TARGET=RISCV64_ZVL128B HOSTCC=gcc BINARY=64 FC=/PATH/to/linux_k230/Xuantie-900-gcc-linux-6.6.0-glibc-x86_64-V3.0.1/bin/riscv64-unknown-linux-gnu-gfortran CC=/PATH/to/Xuantie-900-gcc-linux-6.6.0-glibc-x86_64-V3.0.1/bin/riscv64-unknown-linux-gnu-gcc NOFORTRAN=0 USE_THREAD=0 LIBPREFIX="./libopenblas" LAPACKE="NO_LAPACKE=0" INTERFACE64=0 NO_STATIC=0 NO_SHARED=1 -Wimplicit-functiondeclaration"

@zejianzhang1982
Copy link

zejianzhang1982 commented Dec 5, 2024

hi , I build it with setting the TARGET=C910v
like this make HOSTCC=gcc TARGET=C910V CC=riscv64-unknown-linux-gnu-gcc FC=riscv64-unknown-linux-gnu-gfortran

@martin-frbg
Copy link
Collaborator

martin-frbg commented Dec 6, 2024

My problem is that I don't recall needing the riscv_vector_v0p10_non_policy_common.h when building directly on MILK-V Pioneer (C920V using the C910V target).
Probably the additional include should go into common_riscv64.h where we already have an ifdef block for older T-Head compilers that adds #define RISCV_0p10_INTRINSICS - at least it looks logical to me that the `#include' should be put alongside that define (around line 96 of common_riscv64.h). Would you agree ?

@martin-frbg
Copy link
Collaborator

Hmm. That header file does not appear to exist in the Xuantie-900-gcc-linux-5.10.4-glibc-x86_64-V2.8.0 toolchain that our CI job is using, suggesting we would need at least some kind of version check to distinguish between "your" 6.6-V3.0.1 version of the compiler and "our" older one. @RevySR can you help (again) please ? My being competely illiterate in Chinese does not make it easier for me to even locate the newer version of the compiler, I do not even see anything newer than 2.8.1 from them on github or the English-language section of their xrvm.com site

@zejianzhang1982
Copy link

downalod xuntie gcc tool chain at https://www.xrvm.cn/community/download?id=4382928864901402624

@martin-frbg
Copy link
Collaborator

Thanks - unfortunately that link appears to require registration (including a domestic Chinese telephone number, as far as I managed to figure out) before allowing download

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants