[llvm-dev] Questions about vscale
Kai Wang via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 7 01:30:39 PDT 2020
Hi,
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 =
8
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?
Thanks!
Hsiangkai
-------------- 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