similar to: Questions about vscale

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

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

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

On Wed, 2 Oct 2019 at 05:09, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote: > > My general feeling on this then is that both RVV and SV should avoid using > vscale. > > In the case of RVV, MVL is a hardware defined constant that is never > *intended* to be known by applications. There's no published detection > mechanism. Loops are supposed to be designed

On Tue, Oct 1, 2019 at 8:08 AM Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hello Jacob and Luke, > > First off, even if a dynamically changing vscale was truly necessary > for RVV or SV, this thread would be far too late to raise the question. > That vscale is constant -- that the number of elements in a scalable > vector does not change during program execution

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 >

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

On Tue, Oct 1, 2019 at 11:08 AM 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 ==

Thanks @Robin and @Graham for giving some background on scalable vectors and clarifying some of the details! Apologies if I'm repeating things here, but it is probably good to emphasize the conceptually different, but complementary models for scalable vectors: 1. Vectors of unknown, but constant size throughout the program. 2. Vectors of changing size throughout the program. Where (2)

Hi, I abandoned that approach and followed Eli's suggestion, see somewhere earlier in this thread, and emit an intrinsic that represents/calculates the active mask. I've just uploaded a new revision for D79100 that implements this. Cheers. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 18 May 2020 13:32 To: Sjoerd Meijer <Sjoerd.Meijer at

Hi, i am the main author of RV, the Region Vectorizer (github.com/cdl-saarland/rv). I want to share our standpoint as potential users of the proposed vector-length agnostic IR (RISC-V, ARM SVE). -- support for `llvm.experimental.vector.reduce.*` intrinsics -- RV relies heavily on predicate reductions (`or` and `and` reduction) to tame divergent loops and provide a vector-length agnostic

> You have similar problems with https://reviews.llvm.org/D79100 The new revision D79100<https://reviews.llvm.org/D79100> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics involved at all here. Just to quickly discuss the optimisation pipeline, D79100<https://reviews.llvm.org/D79100> is a small extension for the

On 11/6/20 12:39 PM, Sjoerd Meijer wrote: Hello Simon, Thanks for your replies, very useful. And yes, thanks for the example and making the target differences clear: ; Some examples: ; RISC-V V & VE(*): ; %mask = (splat i1 1) ; %evl = min(256, %n - %i) ; MVE/SVE : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() ; AVX: ; %mask = icmp (%i + (seq

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

Hi, > On 6 Jun 2018, at 17:36, David A. Greene <dag at cray.com> wrote: > > Graham Hunter via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> Ok, now I understand what you're getting at. A ConstantExpr would >>> encapsulate this computation. We alreay have "non-static-constant" >>> values for ConstantExpr like sizeof and

Hi Robin, responses inline. -Graham > On 11 Jun 2018, at 16:47, Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hi Graham, > Hi David, > > glad to hear other people are thinking about RVV codegen! > > On 7 June 2018 at 18:10, Graham Hunter <Graham.Hunter at arm.com> wrote: >> >> Hi, >> >>> On 6 Jun 2018, at 17:36, David A.

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV

On 11/6/20 8:49 AM, Roger Ferrer Ibáñez wrote: Hi Sjoerd, Trying to remember how everything fits together here, but could get.active.lane.mask not create the %mask of the VP intrinsics? Or in other words, in the vectoriser, who's producing the %mask and %evl that is consumed by the VP intrinsics? I'm not sure what would be the best way here. I think about the Loop Vectorizer. I imagine

On Wed, 8 Apr 2020 at 04:23, Kai Wang <kai.wang at sifive.com> wrote: > If we apply the type system pointed out by Renato, is the vector type <vscale x 1 x i16> legal? If we decide that <vscale x 1 x i16> is a fundamentally impossible type, does it contrary to the philosophy of LLVM IR as reasonably target-independent IR? I do not get the point of your argument. Hi Kai,