[RISCV] correct the default VLEN to 128

[jerryzj]

• From the RISCV ISA spec

The V vector extension depends upon the Zvl128b and Zve64d extensions.

Reference: https://github.com/riscv/riscv-isa-manual/blob/e5078e55ea977ef197066dcd3f7c8e09032cb348/src/v-st-ext.adoc?plain=1#L5094

[cbalint13]

Hi @jerryzj !

LLVM side (implicitly TVM) is aware of this already:

$ cat tvm-llvm-rvv.py 
#!/usr/bin/python3

import tvm

target = tvm.target.Target("llvm -device=riscv_cpu -mtriple=riscv32-linux-gnu -mcpu=generic-rv32 -mattr=+i,+m,+v")
print("LLVM [%s]" % target)
print("LLVM features: %s" % (tvm.target.codegen.llvm_get_cpu_features(target)))

$ ./tvm-llvm-rvv.py 
LLVM [llvm -keys=riscv_cpu,cpu -device=riscv_cpu -mattr=+i,+m,+v -mcpu=generic-rv32 -mtriple=riscv32-linux-gnu]
LLVM features: {'zve64x', 'zve32f', 'zve64f', 'zmmul', 'zve64d', 'f', 'zicsr', 'd', 'optimized-nf2-segment-load-store', 'm', 'zve32x', 'zvl32b', 'v', 'zvl128b', 'zvl64b', '32bit', 'i'}

Notice the presence of zvl128b, that was added due to +v presence, so this will be properly picked up anyway.

---

BUT, please note that in the case of no +v (absence) we still need a default TVM vector width, and this one has nothing to do with the ISA anymore, but yes let's settle it to 128 (down from current 256).

I am just working right now on refactoring RISCV target to also enable the SVE predication, will reference this PR.

[jerryzj]

Please refer to the ISA spec, the minimum vector length can be set via zvl<?>b

[cbalint13]

Please refer to the ISA spec, the minimum vector length can be set via zvl<?>b

• TVM is/was aware of this already.

Your code here touch the case for NO "v" extension presence, where TVM still needs a hint, but lets settle even this to 128.

[jerryzj]

Please refer to the ISA spec, the minimum vector length can be set via zvl<?>b

• TVM is/was aware of this already.

Your code here touch the case for NO "v" extension presence, where TVM still needs a hint, but lets settle even this to 128.

If there is no v, zve* or other zvl specified, meaning that current CPU is not supporting vector operations hence no vector registers, why not set VLEN to 0?

[cbalint13]

If there is no v, zve* or other zvl specified, meaning that current CPU is not supporting vector operations hence no vector registers, why not set VLEN to 0?

Currently vector_with != VLEN, it only becomes equivalent (and useful) with VLEN in case of SVE support (WiP).
There is a refactor effort of what is described here: #17859 , making things clear.

---

TVM is relaying on LLVM (well maintained) as root of trust , it extract "arch knowledge" from, not vice-versa:

Few outcomes for riscv case:

1. If no v present, or whatever other arch it is, we still need a vector_with for TVM alignment hints (but doesn't really matter).
2. If only v is present, but no extra attributes, then a zvl128b will be implicitly present, it will be added by LLVM library (due to ISA spec you mentioned)
3. If v is present, and extra attributes like +zvl1024b as override, then largest one will be picked up (still from LLVM library).
4. If no attributes are present but cpu is a known vendor one like -mcpu=sifive-x280 then zvl512b will be picked up from LLVM library side.

TVM only extracts zvl<XXX>b from LLVM library (riscv case), if they do something wrong TVM is also doing wrong.
See full scenarios that are checked as target tests: tests/python/target/test_riscv_features.py

One can use the sample code (posted here on top) to check what kind of features for various targets are yielded.

[cbalint13]

@jerryzj

To further clarify where this vector_width ends up:

• Targets having different maintainers, with specific codegen overrides, where original vector_width is not even used:
  https://github.com/search?q=repo%3Aapache%2Ftvm%20native_vector_bits_&type=code

• The only place that really picks it up is the llvm codegen backend:
  

  tvm/src/target/llvm/codegen_llvm.cc

  Line 176 in 36f2502

  native_vector_bits_ = llvm_target_->GetVectorWidth();

• In this context, the only place it really propagates is into GetAlignment() , but even here is used as a last resort hint.

Up to this point we can sayvector_width != VLEN (no such relationship), but also can't set it to 0 (zero).
E.g. in case of x86 it is set to maximal 512 (for avx512) but in reality only few server class CPU have such vector feature.

Now, in the context of SVE (WiP) it will be really picked up and used to construct a list of vscale_range hints for arith provers in the SVE predication process. But SVE, in case of riscv, always implies that target have v extension, and also a minimum default zvl128b flag that will be picked up for sure from LLVM side. In this case vector_width == VLEN will be true here. This schema also will work for aarch64 SVE predication, the initial hint value of 128 will be used unaltered, this arch doesnt have so fancy flags with direct indication on the kind of vector machine.

In last instance if someone really want to enforce other initial hint value, (assuming really knowing what is doing) can override even this initial hint using -vector-width=xxx but this will get override in the case of exact inference from LLVM side (in case of riscv rvv for sure).

---

In the future, I would completely remove this confusing vector_width and realted codebits, and relay only on LLVM provided infos, but this will require some careful work spanning all involved targets, as a first step need to see how that alignment information could be extracted.

---

Let's set it to 128 as you proposed as a initial hint value, but this PR here failed to pass testcases otherwise it LGTM.