search for: lmul

..., 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 in...

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 i...

Hi all, On Tue, 7 Apr 2020 at 11:04, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 7 Apr 2020 at 09:30, Kai Wang via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 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 | vsc...

On Tue, 7 Apr 2020 at 16:09, Renato Golin <rengolin at gmail.com> wrote: > > On Tue, 7 Apr 2020 at 12:51, Hanna Kruppe <hanna.kruppe at gmail.com> wrote: > > > 1. is LMUL always a multiple of ELEN? > > This happens to be true (at least in the current spec, disregarding > > some in-progress proposals) just because both are powers of two and > > the largest possible LMUL equals the smallest possible ELEN (8), but I > > don't think there is...

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`: > > The scalable vector type in

...le vector type proposal from top to bottom and in fact > was one of the conditions for its acceptance... that should be explicitly made clear in the patches. it sounds very much like it's only suitable for statically-allocated arrays-of-vectorisable-types: typedef vec4 float[4]; // SEW=32,LMUL=4 probably static vec4 globalvec[1024]; // vscale == 1024 here or, would it be intended for use inside functions - again statically-allocated? int somefn(void) { static vec4 localvec[1024]; // vscale == 1024 here } *or*, would it be intended to be used like this? int somefn(num_of_vec4s) { s...

...;s required (i.e., you can't sensibly write the program otherwise) and perfectly fine w.r.t. portability. One example is the stack frame layout when there's any vectors on the stack (e.g. for spills), since the vector stack slots must in general be large enough to hold a full vector (= VLEN*LMUL bits). Granted, I don't think this or other examples will normally occur in LLVM IR generated by a loop vectorizer, so vscale will probably not occur very frequently in RVV. Nevertheless, there is nothing inherently non-portable about it. Regards Robin PS: I don't want to read too much in...

...;> was one of the conditions for its acceptance... >> >> that should be explicitly made clear in the patches. it sounds very >> much like it's only suitable for statically-allocated >> arrays-of-vectorisable-types: >> >> typedef vec4 float[4]; // SEW=32,LMUL=4 probably >> static vec4 globalvec[1024]; // vscale == 1024 here > > 'vscale' just refers to the scaling factor that gives the maximum size of > the vector at runtime, not the number of currently active elements. > > SVE will be using predication alone to deal with d...

Hi Everyone, I am wondering how to use RISC-V V (Vector) extension instructions in LLVM IR. In 2019 Kruppe and Espasa gave a talk [1] overviewing the Vector extension and on slide 16 [2] they show LLVM IR samples which use the vector instructions through intrinsic functions, such as: %vl = call i32 @llvm.riscv.vsetvl(i32 %n) At the time of the talk (April 2019) LLVM support for the V

Hi Luke, > was it intentional to leave out both jacob and myself? > [...] > if that was a misunderstanding or an oversight i apologise for raising it. It was definitely not my intention to be non-inclusive, my apologies if that seemed the case! > can i therefore recommend a change, here: > [...] > "This patch adds vscale as a symbolic constant to the IR, similar to >

...Graham Hunter <Graham.Hunter at arm.com> wrote: > Hi Luke, hi graham, thanks for responding in such an informative fashion. > > On 1 Oct 2019, at 09:21, Luke Kenneth Casson Leighton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > typedef vec4 float[4]; // SEW=32,LMUL=4 probably > > static vec4 globalvec[1024]; // vscale == 1024 here > > 'vscale' just refers to the scaling factor that gives the maximum size of > the vector at runtime, not the number of currently active elements. ok, this starts to narrow down the definition. i'm atte...