[llvm-dev] Questions about vscale

Kai Wang via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 7 01:30:39 PDT 2020


In RISC-V v-extension, operations could operate on a group of vector
registers; we called it LMUL. If LMUL equals 2, it means we could operate
on 2 vector registers at the same time. So, we have the following
combinations of types.

          LMUL = 1           LMUL = 2            LMUL = 4            LMUL =

int64_t | vscale x 1 x i64 | vscale x  2 x i64 | vscale x  4 x i64 | vscale
x  8 x i64

int32_t | vscale x 2 x i32 | vscale x  4 x i32 | vscale x  8 x i32 | vscale
x 16 x i32

int16_t | vscale x 4 x i16 | vscale x  8 x i16 | vscale x 16 x i16 | vscale
x 32 x i16

 int8_t | vscale x 8 x i8  | vscale x 16 x i8  | vscale x 32 x i8  | vscale
x 64 x i8

We have another architecture parameter, ELEN, which means the maximum size
of a single vector element in bits.

We hope the type system could be consistent under ELEN = 32 and ELEN = 64.
However, vscale may be a fractional value under ELEN = 32 in the above type
system. When ELEN = 32, i64 is an invalid type (we could ignore the first
row for ELEN = 32) and vscale may become 1/2 on run time to fit the
architecture (if the vector register only has 32 bits). Is there any
problem to assume vscale to be fractional under some circumstances? vscale
should be an unknown value when compiling. So, it should have no impact on
code generation and optimization. The relationship between types is correct
regardless vscale’s value. Is there anything I missed?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/335fa446/attachment.html>

More information about the llvm-dev mailing list