Problem using LLVM with RISC-V vector extension

[riscv21]

Hi all,

Since LLVM supports riscv vector extension (v0.10), I’m using LLVM to auto-vectorize my code.

I followed the steps mentioned in sifive riscv-llvm repo to install llvm, and it was successful. I was able to compile the program with -v flag using this command:
clang -c hello.c -menable-experimental-extensions -march=rv64gcv0p10 -target riscv64 -O3 -mllvm --riscv-v-vector-bits-min=256

As suggested in that repo, I used gcc for the final link:
riscv64-unknown-elf-gcc hello.o -o hello

This causes the following error message:

riscv64-unknown-elf/bin/ld:  -march=rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_v0p10_zvlsseg0p10: unknown z ISA extension `zvlsseg'
riscv64-unknown-elf/bin/ld: failed to merge target specific data of file hello.o

Then I tried building llvm linker project itself, but using ld.lld hello.o -o hello is also causing an error:
ld.lld: error: undefined symbol: puts
referenced by hello.c
hello.o:(main)

Any idea how I can fix these issues with gcc and llvm linkers?

Thank you!

[Sober Liu]

Maybe you could try to keep use clang (lld) with option --gcc-toolchain=<gcc_path>, to get libc supports (e.g., newlib) from gcc build.

 

From: riscv21 <zahra...@gmail.com>
Sent: 2021年8月2日 14:04
To: RISC-V SW Dev <sw-...@groups.riscv.org>
Subject: [sw-dev] Problem using LLVM with RISC-V vector extension

 

External email: Use caution opening links or attachments

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/bd2ce74b-c0a1-4cfa-afe9-356e856d5cdcn%40groups.riscv.org.

[riscv21]

Hi,

Thank you Soberl!

I passed the include and library paths as well as the gcc-toolchain to clang, and it is now generating the binary without any errors.

However, the problem is that when clang generates only the assembly file the vector encoding is known, 

but if it generates the binary file directly and I use the objdump to dump the object file, all the vector instructions are "unknown".

So Spike also throws invalid instruction errors on vector instructions because they are unknown.

Any idea what I'm missing here?

These are the commands I'm using:

$VPU/install/riscv-llvm/bin/clang  -I$VPU/install/riscv-gcc/riscv64-unknown-elf/include/ \

 -L$VPU/install/riscv-gcc/riscv64-unknown-elf/lib \

  --gcc-toolchain=$VPU/riscv-gcc/riscv64-unknown-elf/  \

-march=rv64gcv0p10  -mllvm --riscv-v-vector-bits-min=256  \

-menable-experimental-extensions -mno-relax -fuse-ld=lld  -O3  -o vec_test vec_test.c

$VPU/install/riscv-isa-sim/bin/spike  $VPU/install/riscv-gcc/riscv64-unknown-elf/bin/pk  vec_test

Thank you!

[Sober Liu]

Spike should be able to execute RVV instructions, have u used options like “--isa=RV$(XLEN)IMAFDCV --varch=vlen:$(VLEN),elen:128,slen:$(VLEN)”, to enable V ext and set VLEN?

[Bruce Hoult]

Note, the concept of SLEN has not existed in the V extension for some time now. Effectively SLEN is always VLEN.

Also, ELEN greater than XLEN would be very unusual. In fact ELEN greater than 32 (both integer and FP) would be somewhat unusual, though permitted.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/DM8PR12MB5416ADDCCA75ADC945F0457DADF19%40DM8PR12MB5416.namprd12.prod.outlook.com.

[Jim Wilson]

On Tue, Aug 3, 2021 at 9:53 PM riscv21 <zahra...@gmail.com> wrote:

However, the problem is that when clang generates only the assembly file the vector encoding is known, 

but if it generates the binary file directly and I use the objdump to dump the object file, all the vector instructions are "unknown".

So Spike also throws invalid instruction errors on vector instructions because they are unknown.

You need an objdump that has vector support.  Unlike clang, the vector support is not on mainline in the GNU toolchain.  In FSF Binutils, there is a users/riscv/binutils-integration-branch that has the vector support.  In riscv-gnu-toolchain, there is a rvv-intrinsic branch that has vector support, but this is not well maintained and not recommended for use, and may not be compatible with your clang and spike sources as it may not implement the exact same rvv draft spec version.

Jim

[riscv21]

Thank you Soberl and Jim!

Using --isa and --varch solved the Spike errors. 

I'm using Spike debug mode, "reg 0 a0" prints a0 register values. 

How can we see the content of vector registers? "reg 0 v0-31" doesn't work.

I'm using llvm-objdump which is installed as part of llvm toolchain. 

So I expected it to support vector extension.  

--arch-name only has "riscv32/64" available as targets.

should I use any other flags?

Thank you!

[risc-v id]

Hi all, 

I used clang to vectorize the code for vlen=256 using the following flags:

-menable-experimental-extensions -march=rv64gcv0p10  -O3 -static -v -mllvm  --riscv-v-vector-bits-min=256

Then I used Spike to run the code with vlen=256 and elen=64, and it worked fine.

However, I get illegal instruction error for elen=32. 

What is the min value for elen? 8<=elen<=vlen?  

spike  --isa=RV64IMAFDCV   --varch=vlen:256,elen:32 pk -s test_prog

bbl loader
z 0000000000000000 ra 0000000000016ec0 sp 0000003ffffff7d0 gp 000000000008b0d0
tp 000000000008cac0 t0 0000000000000ff0 t1 000000000002d51a t2 0000000000000000
s0 0000003ffffff8c0 s1 000000000008d1c0 a0 3ffffffffffffffe a1 00000000000951c0
a2 00000000000991c0 a3 0000000000002000 a4 0000003ffffff8f8 a5 000000000009d1c0
a6 0000000000000008 a7 000000000009f1c0 s2 0000000000001000 s3 0000000000000000
s4 00000000000103c8 s5 00000000ffffffff s6 000000000000003a s7 000000000008b000
s8 0000000000000000 s9 0000000000000000 sA 0000000000000000 sB 000000000008d1c0
t3 000000000000007c t4 0000000000000000 t5 0000000000000000 t6 0000000000000000
pc 000000000005346e va/inst 000000005e003cd7 sr 8000000200006620

An illegal instruction was executed!

Thanks!

[Bruce Hoult]

The single-letter V extension is intended for use in application processor profiles.

The V vector extension depends upon the Zvl128b extension.

The V extension supports EEW of 8, 16, and 32, and 64.

If you don't want code generated using 64 bit elements then you have to tell the compiler to use one of the embedded profiles e.g. Zve32x or Zve32f

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/d82ef379-6b80-4b04-9108-9fc993b20c02n%40groups.riscv.org.

[Bruce Hoult]

As I said in my previous email, the "V" extension supports all eew from 8 to 64.

Certainly this means you can compile and run code that uses 32 bit elements. But the compiler is free to generate code using 64 bit elements too, for example if it auto-vectorises a loop. Or some library function might use 64 bit elements. It's allowed to.

Spike is giving you an illegal instruction exception when you tell spike elen=32 but not when elen=64. This suggests that your code (or some library code) at some point sets elen=64.

We can't see your code. All we know is that your exception happens with an opcode of 5e003cd7 (vmv.v.i v25,0) at address 5346e. We would have to see the preceding vsetvli to understand why. But my guess is it includes "e64".

On Thu, Oct 28, 2021 at 4:02 PM risc-v kimi <ris...@gmail.com> wrote:

Thank you Bruce!

So if the single letter v extension supports eew of 32, I should be able to compile the code for 32-bit elements even without using zve32x (just with -march=rv64gcv0p10), right? 

Is there any option to pass the element width to the compiler? 

[risc-v kimi]

I misunderstood that, thanks Bruce for explaining!

So compiled code with the v extension is free to use all the mentioned eews, and we can't force the compiler to use a specific one. 

I checked the code, your guess is correct.

  5346a: c5817057            vsetivli  zero,2,e64,m1,ta,mu
   5346e: 5e003cd7            vmv.v.i v25,0
   53472: 02077ca7            vse64.v v25,(a4)

Just one more question, how should I pass the zve32x to clang compiler? -march=rv64gczve32x doesn't work. 

[Peter Lieber]

Did you get this working? I'm trying to run an intrinsic example (rvv_saxpy.c) and get an illegal instruction error. The default varch is 128 and 64, but the help in spike does still mention slen, which I find odd.  

[Peter Lieber]

My illegal instruction is csrr, which should be valid: 

c22026f3                csrr    a3,0xc22

It is just reading vlenb into a3... I tried calling with elen both at 32 and 64, but I don't think this should affect this instruction itself.

[Andrew Waterman]

Make sure mstatus.FS and misa.V are nonzero.  Those are the only things that should preclude access to the vlenb CSR.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/1a990944-eca9-4d67-87de-f4f93cbf04fcn%40groups.riscv.org.

[Peter Lieber]

Well, at bootup, mstatus.FS and misa.V are both 0. This led to the face-palm discover that I had the --isa=RV64GCV argument on the wrong side of my pk rvv_saxpy.elf arguments.  Now, with the following command, I can run this code:

spike --isa=RV64GCV pk rvv_saxpy.elf

Thank you all for your help.