Hi,
Looking at the language reference, vscale is an integer. This might pose a
problem for fractional vscale. Furthermore, I believe that vscale is constant
throughout the life of the program; so if RISC-V vscale can vary from
instruction to instruction that may also be problematic unless you can just
commit to one specific value of vscale.
Also, I had a question about your table. Based on your description of how
LMUL works, I’d expect that LMUL == vscale, and that each column in your table
would be the same:
int64_t | vscale x 1 x i64
int32_t | vscale x 2 x i32
int16_t | vscale x 4 x i16
int8_t | vscale x 8 x i8
… which is basically equivalent to:
int64_t | LMUL x 1 x i64
int32_t | LMUL x 2 x i32
int16_t | LMUL x 4 x i16
int8_t | LMUL x 8 x i8
… is this not the case?
Thanks,
Chris Tetreault
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Kai Wang via llvm-dev
Sent: Tuesday, April 7, 2020 1:31 AM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Cc: Roger Ferrer Ibanez <roger.ferrer at bsc.es<mailto:roger.ferrer at
bsc.es>>; rengolin at gmail.co<mailto:rengolin at gmail.co>;
robin.kruppe at gmail.com<mailto:robin.kruppe at gmail.com>
Subject: [EXT] [llvm-dev] Questions about vscale
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/42c81c72/attachment-0001.html>
Hi Chris, vscale is constant in RISC-V as well. It doesn't change from instruction to instruction. There are two implementation parameters of the RISC-V V-extension called VLEN, the number of bits of a (base) vector register, and ELEN, the maximum width in bits of an element in a vector register (i.e. if ELEN=32 one can't operate vectors of i64 or f64). Ideally we'd want to make the compiler as oblivious as possible to these parameters as we can. VLEN itself is not that different to the SVE situation. ELEN is a bit different because it impacts what vector types are legal in the code generator, this in turns impacts other parts like the loop vectorizer. It seems reasonable to make vscale = VLEN / ELEN. In this model, assume ELEN=64, legal types include <vscale x 1 x i64> and <vscale x 2 x i32>. As the ISA stands now, it is not efficient to operate, still in ELEN=64, a value of type <vscale x 1 x i32> so it seems reasonable not to make them legal. However in ELEN=32, <vscale x 1 x i32> is a sensible thing. LMUL is a way that the ISA provides to operate groups of registers (which is useful in a number of cases I won't go into details here). There are 32 (base) vector registers (i.e. LMUL=1). LMUL=2 means grouping them in groups of two, LMUL=4 in groups of 4 and so on, up to LMUL=8. So, under LMUL=2, there are 16 groups, twice the length of the base vector registers, under LMUL=4 there are 8 groups, four times the length of the base registers. The ISA allows using these groups as registers so they can be modelled as "super registers" of the base registers (or the opposite, base registers can be seen as subregisters of group registers). Continuing with the model above (ELEN=64), an LMUL=2 group would be able to represent IR values of <vscale x 2 x i64> and <vscale x 4 x i32>. An LMUL=4 group can represent IR values of <vscale x 4 x i64>, <vscale x 8 x i32>, and so on. Kai original question is related to the fact that vscale depends on ELEN and this has the effect that it impacts the legal types. So one modelling option is try to get rid of such dependence on ELEN and fix it, say, to 64. Under this approach, legal values would always be, regardless of ELEN, <vscale x 1 x i64>, <vscale x 2 x i32>. As Hannah has pointed in an earlier answer, this may lead to nonsensical (regardless of legalization) IR types. Hope this helps. Kind regards, Missatge de Chris Tetreault via llvm-dev <llvm-dev at lists.llvm.org> del dia dt., 7 d’abr. 2020 a les 18:39:> Hi, > > > > Looking at the language reference, vscale is an integer. This might > pose a problem for fractional vscale. Furthermore, I believe that vscale is > constant throughout the life of the program; so if RISC-V vscale can vary > from instruction to instruction that may also be problematic unless you can > just commit to one specific value of vscale. > > > > Also, I had a question about your table. Based on your description of > how LMUL works, I’d expect that LMUL == vscale, and that each column in > your table would be the same: > > > > > > int64_t | vscale x 1 x i64 > > int32_t | vscale x 2 x i32 > > int16_t | vscale x 4 x i16 > > int8_t | vscale x 8 x i8 > > > > … which is basically equivalent to: > > > > int64_t | LMUL x 1 x i64 > > int32_t | LMUL x 2 x i32 > > int16_t | LMUL x 4 x i16 > > int8_t | LMUL x 8 x i8 > > > > > > … is this not the case? > > > > Thanks, > > Chris Tetreault > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Kai > Wang via llvm-dev > *Sent:* Tuesday, April 7, 2020 1:31 AM > *To:* llvm-dev at lists.llvm.org > *Cc:* Roger Ferrer Ibanez <roger.ferrer at bsc.es>; rengolin at gmail.co; > robin.kruppe at gmail.com > *Subject:* [EXT] [llvm-dev] Questions about vscale > > > > 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Roger Ferrer Ibáñez -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/c17a846e/attachment-0001.html>
OK, I see now. The original email did not mention VLEN, so I assumed LMUL was
VLEN. This makes sense.
I guess my original point about vscale being an integer still stands though. If
VLEN / ELEN is computed using integer arithmetic, then the result rounded
towards 0 is 0. Unless we make floating point vscale a thing, it should be
impossible for vscale to be fractional.
From: Roger Ferrer Ibáñez <rofirrim at gmail.com>
Sent: Tuesday, April 7, 2020 11:26 AM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Kai Wang <kai.wang at sifive.com>; Roger Ferrer Ibanez
<roger.ferrer at bsc.es>; llvm-dev at lists.llvm.org; rengolin at
gmail.co; robin.kruppe at gmail.com
Subject: [EXT] Re: [llvm-dev] Questions about vscale
Hi Chris,
vscale is constant in RISC-V as well. It doesn't change from instruction to
instruction.
There are two implementation parameters of the RISC-V V-extension called VLEN,
the number of bits of a (base) vector register, and ELEN, the maximum width in
bits of an element in a vector register (i.e. if ELEN=32 one can't operate
vectors of i64 or f64). Ideally we'd want to make the compiler as oblivious
as possible to these parameters as we can. VLEN itself is not that different to
the SVE situation. ELEN is a bit different because it impacts what vector types
are legal in the code generator, this in turns impacts other parts like the loop
vectorizer.
It seems reasonable to make vscale = VLEN / ELEN.
In this model, assume ELEN=64, legal types include <vscale x 1 x i64> and
<vscale x 2 x i32>. As the ISA stands now, it is not efficient to operate,
still in ELEN=64, a value of type <vscale x 1 x i32> so it seems
reasonable not to make them legal. However in ELEN=32, <vscale x 1 x i32>
is a sensible thing.
LMUL is a way that the ISA provides to operate groups of registers (which is
useful in a number of cases I won't go into details here). There are 32
(base) vector registers (i.e. LMUL=1). LMUL=2 means grouping them in groups of
two, LMUL=4 in groups of 4 and so on, up to LMUL=8. So, under LMUL=2, there are
16 groups, twice the length of the base vector registers, under LMUL=4 there are
8 groups, four times the length of the base registers. The ISA allows using
these groups as registers so they can be modelled as "super registers"
of the base registers (or the opposite, base registers can be seen as
subregisters of group registers).
Continuing with the model above (ELEN=64), an LMUL=2 group would be able to
represent IR values of <vscale x 2 x i64> and <vscale x 4 x i32>. An
LMUL=4 group can represent IR values of <vscale x 4 x i64>, <vscale x 8
x i32>, and so on.
Kai original question is related to the fact that vscale depends on ELEN and
this has the effect that it impacts the legal types. So one modelling option is
try to get rid of such dependence on ELEN and fix it, say, to 64. Under this
approach, legal values would always be, regardless of ELEN, <vscale x 1 x
i64>, <vscale x 2 x i32>. As Hannah has pointed in an earlier answer,
this may lead to nonsensical (regardless of legalization) IR types.
Hope this helps.
Kind regards,
Missatge de Chris Tetreault via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> del dia dt., 7
d’abr. 2020 a les 18:39:
Hi,
Looking at the language reference, vscale is an integer. This might pose a
problem for fractional vscale. Furthermore, I believe that vscale is constant
throughout the life of the program; so if RISC-V vscale can vary from
instruction to instruction that may also be problematic unless you can just
commit to one specific value of vscale.
Also, I had a question about your table. Based on your description of how
LMUL works, I’d expect that LMUL == vscale, and that each column in your table
would be the same:
int64_t | vscale x 1 x i64
int32_t | vscale x 2 x i32
int16_t | vscale x 4 x i16
int8_t | vscale x 8 x i8
… which is basically equivalent to:
int64_t | LMUL x 1 x i64
int32_t | LMUL x 2 x i32
int16_t | LMUL x 4 x i16
int8_t | LMUL x 8 x i8
… is this not the case?
Thanks,
Chris Tetreault
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> On Behalf Of Kai Wang via llvm-dev
Sent: Tuesday, April 7, 2020 1:31 AM
To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Cc: Roger Ferrer Ibanez <roger.ferrer at bsc.es<mailto:roger.ferrer at
bsc.es>>; rengolin at gmail.co<mailto:rengolin at gmail.co>;
robin.kruppe at gmail.com<mailto:robin.kruppe at gmail.com>
Subject: [EXT] [llvm-dev] Questions about vscale
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
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/00bf22b3/attachment-0001.html>