search for: vscale

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

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

...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 | vscale x 8 x i16 | vscale x 16 x i16 | vscale x 32 x i16 > > int8_t | vscale x 8 x i8...

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

...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) basically builds on (1). LLVM's scalable vectors support (1) directly. The scalable type is defined using the concept `vscale` that is constant throughout the program and expresses the unknown, but maximum size of a scalable vector. My patch builds on that definition by adding `vscale` as a keyword that can be used in expressions. For this model, predication can be used to disable the lanes that are not needed. Given that...

...ther by "this" you mean ELEN, LMUL, or something > > else. ELEN is fixed in hardware. LMUL is a property of each individual > > instruction. > > Sorry again, "this" as in both ELEN and LMUL and their relationship. Ack. > > > I don't know what "vscale wouldn't apply" is supposed to mean. > > Legalisation-wise, you got right, like <n x 0.5 x i64> is invalid and > gets converted to <n x 1 x i32>, which it is. > > "Wouldn't apply" as in "what would be the point of having half-scale > on a ty...

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

...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 > undef and zeroinitializer, so that vscale - representing the > runtime-detected "element processing" capacity - can be used in > constant expressions" Thanks for the suggestion! I like the use of the word `capacity` especially n...

On 08/01/2018 06:15 AM, Renato Golin wrote: > On Tue, 31 Jul 2018 at 23:46, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> In some sense, if you make vscale dynamic, >> you've introduced dependent types into LLVM's type system, but you've >> done it in an implicit manner. It's not clear to me that works. If we >> need dependent types, then an explicit dependence seems better. (e.g., >> <scalable <n> x %v...

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 -- is baked into the > accepted scalable vector type proposal from top t...

Hi David, Let me put the last two comments up: > > But we're trying to represent slightly different techniques > > (predication, vscale change) which need to be tied down to only > > exactly what they do. > > Wouldn't intrinsics to change vscale do exactly that? You're right. I've been using the same overloaded term and this is probably what caused the confusion. In some cases, predicating and shortening t...

I've run update_llc_test_checks on a set of tests and am seeing some weird behavior. The CHECK lines appear directly after the function's first line, even if there are multiple arguments. E.g.: define <vscale x 4 x i32> @sel_nxv4i32(<vscale x 4 x i1> %p, ; CHECK-LABEL: sel_nxv4i32: ; CHECK: // %bb.0: ; CHECK-NEXT: mov z0.s, p0/m, z1.s ; CHECK-NEXT: ret <vscale x 4 x i32> %dst, <vscale x 4 x i32&gt...

...ssert that the type >> isn't scalable. > > Can you explain a bit about what the two integers represent? What's the > "unscaled" part for? 'Unscaled' just means 'exactly this many bits', whereas 'scaled' is 'this many bits multiplied by vscale'. > > The name "getSizeExpressionInBits" makes me think that a Value > expression will be returned (something like a ConstantExpr that uses > vscale). I would be surprised to get a pair of integers back. Do > clients actually need constant integer values or would a...

...t; 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 attempting to get clarity on what it means. so, in the example...

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 to run a few more times on > lower spec'd hardware. > > Robin, what's y...

...are questions that will come up if/when we tackle VL. > >> At some point in the future I will propose something in this space to >> support RISC-V vectors, but we'll cross that bridge when we come to >> it. > Sounds good. > >> Yes, for RISC-V we definitely need vscale to vary a bit, but are fine >> with limiting that to function boundaries. The use case is *not* >> "changing how large vectors are" in the middle of a loop or something >> like that, which we all agree is very dubious at best. The RISC-V >> vector unit is just very...

...sts.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi David, >> >> Let me put the last two comments up: >> >>> > But we're trying to represent slightly different techniques >>> > (predication, vscale change) which need to be tied down to only >>> > exactly what they do. >>> >>> Wouldn't intrinsics to change vscale do exactly that? >> >> You're right. I've been using the same overloaded term and this is >> probably what caused the confu...

Hi David, >>> The name "getSizeExpressionInBits" makes me think that a Value >>> expression will be returned (something like a ConstantExpr that uses >>> vscale). I would be surprised to get a pair of integers back. Do >>> clients actually need constant integer values or would a ConstantExpr >>> sufffice? We could add a ConstantVScale or something to make it work. >> >> I agree the name is not ideal and I'm open to sug...

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, Don't worry about target-independent IR in your design of int...

...Jan 2020 at 08:22, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > This fixed list of shuffles makes me uncomfortable, and I wonder if > there isn't a much simpler solution to the problem. Specifically, > allow the IR form: > > %result = shufflevector <vscale x n x TY> %v1, <vscale x n x TY> %v2, > <m x i32> <mask> > > yielding a result of type <vscale x m x TY>. (The <mask> could still > just be a constant list of integers, i.e. this doesn't require a > relaxation to arbitrary Value* masks.) Back whe...