search for: scalabl

...2/2/19 1:39 AM, Luke Kenneth Casson Leighton wrote: > > > On Friday, February 1, 2019, Simon Moll <moll at cs.uni-saarland.de > <mailto:moll at cs.uni-saarland.de>> wrote: > > We could untie the mask length from the data length: > >   %result = call <scalable 4 x float> > @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4 x float> > %y, <scalable 1 x i1> %M, i32 %L) > > would then indicate the mask %M applies to groups of "4 / 1" float > elements. > > > That would provide the...

...SVE instructions from that IR. These patches (listed in section 7 of > this rfc) can be found on Phabricator and are intended to illustrate the scope > of changes required by the general approach described in this RFC. > > ========== > Background > ========== > > *ARMv8-A Scalable Vector Extensions* (SVE) is a new vector ISA extension for > AArch64 which is intended to scale with hardware such that the same binary > running on a processor with longer vector registers can take advantage of the > increased compute power without recompilation. > > As the vector...

...imple vectorized loop in IR and generate SVE instructions from that IR. These patches (listed in section 7 of this rfc) can be found on Phabricator and are intended to illustrate the scope of changes required by the general approach described in this RFC. ========== Background ========== *ARMv8-A Scalable Vector Extensions* (SVE) is a new vector ISA extension for AArch64 which is intended to scale with hardware such that the same binary running on a processor with longer vector registers can take advantage of the increased compute power without recompilation. As the vector length is no longer a co...

...ze, dynamically allocate space, and transparently save and restore the contents of a vector register or registers. On Fri, May 24, 2019 at 11:28 AM JinGu Kang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Graham, > > I am working on a custom target and it is considering scalable vector type representation in programming language. While I am collecting the information about it, I have met your RFC. I have a question. I think the one of fundamental issues is that we do not know the memory layout of the type at compile time. I am not sure whether the RFC covers this issue or...

...those > >> architectures that need it by pulling the multiplication out and > >> switching to the data vector variants. > > Would it make sense to have two different intrinsics? > > > > # "Normal" form, L is in terms of flat vector length. > > <scalable 2 x float> evl.fsub(<scalable 2 x float> %x, > > <scalable 2 x float> %y, > > <scalable 2 x i1> %M, i32 %L) > > > > # "Sub-vector" form, L is in terms of sub-vectors elements. >...

JinGu: I’m not Graham, but you might find the following link a good starting point. https://community.arm.com/developer/tools-software/hpc/b/hpc-blog/posts/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture The question you ask doesn’t have a short answer. The compiler and the instruction set design work together to allow programs to be compiled without knowing until run-time what the vector width is (within limits of min and max possible widths). On...

...ixed-vector-length architectures, but some of the design decisions that it forces, such as having explicit intrinsics for reductions and other horizontal operations, seem like the right direction regardless. I have two questions: 1. > This is a proposal for how to deal with querying the size of scalable > types for > > analysis of IR. While it has not been implemented in full, Is this still true? The details here need to all work out, obviously, and we should make sure that any issues are identified. 2. I know that there has been some discussion around support for changing the vector...

...gt; > > You are referring to the sub-vector sizes, if i am understanding > > correctly. I'd assume that the mask sub-vector length always has to be > > either 1 or the same as the data sub-vector length. For example, this > > is ok: > > > > %result = call <scalable 3 x float> @llvm.evl.fsub.v4f32(<scalable 3 x > > float> %x, <scalable 3 x float> %y, <scalable 1 x i1> %M, i32 %L) > > What does <scalable 1 x i1> applied to <scalable 3 x float> mean? I > would expect a requirement of <scalable 3 x i1>. At...

Hi all, It's been a while since we've given an update on scalable vector support in LLVM. Over the last 12 months a lot of work has been done to make LLVM cope with scalable vectors. This effort is now starting to bear fruit with LLVM gaining more capabilities, including an intrinsics interface for AArch64 SVE/SVE2, LLVM IR Codegen for scalable vectors, and seve...

Hi All, I have read the links from Joel. It seems one of its main focus is vectorization of loop with vector predicate register. I am not sure we need the scalable vector type for it. Let's see a simple example from the white paper. 1 void example01(int *restrict a, const int *b, const int *c, long N) 2 { 3 long i; 4 for (i = 0; i < N; ++i) 5 a[i] = b[i] + c[i]; 6 } We could imagine roughly the vectorized loop with mask on IR l...

...The RISC-V V extension is similar, though has a few extra bits to worry about. You'll need to ask Robin Kruppe if you want more details on that. As far as your question on memory layout is concerned, we don't expect many base 'load' or 'store' instructions to be used for scalable vector types, and for an extremely conservative approach you could consider such a memory operation to potentially alias all memory in a given address space. Instead, we expect to always use masked load and store intrinsics (or gather/scatter intrinsics), and we will need to improve parts of AA to...

...; vector. we could legalize the mask vector variant for those > architectures that need it by pulling the multiplication out and > switching to the data vector variants. Would it make sense to have two different intrinsics? # "Normal" form, L is in terms of flat vector length. <scalable 2 x float> evl.fsub(<scalable 2 x float> %x, <scalable 2 x float> %y, <scalable 2 x i1> %M, i32 %L) # "Sub-vector" form, L is in terms of sub-vectors elements. <scalable 1 x <2 x float>> evl.fsu...

Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType t...

...implicitly reads-only %vlen_state llvm.vla.fadd.f64(f64, f64)           ; implicitly reads-only %vlen_state llvm.vla.fdiv.f64(f64, f64)           : .. same ; this implements the "speculative" load mentioned in the quote above (writes %vlen_state. I suppose it also reads it first?) <scalable 1 x f64> llvm.riscv.probe.f64(%ptr) By relying on memory dependence, this also implies that arithmetic operations can be re-ordered freely as long as vlen_state does not change between them (SLP, "loop mix (CGO16)", ..). Regarding function calls, if the callee does not have the &...

Hi, I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take (isa<VectorType>(Ty) && !isa<FixedVectorType>(Ty)) to mean "is a scalable vector". This is...

...e referring to the sub-vector sizes, if i am understanding >> > correctly. I'd assume that the mask sub-vector length always has to be >> > either 1 or the same as the data sub-vector length. For example, this >> > is ok: >> > >> > %result = call <scalable 3 x float> @llvm.evl.fsub.v4f32(<scalable 3 x >> > float> %x, <scalable 3 x float> %y, <scalable 1 x i1> %M, i32 %L) >> >> What does <scalable 1 x i1> applied to <scalable 3 x float> mean? I >> would expect a requirement of <scalable...

Hi Alex, We've only recently managed to get the core scalable vector IR type into the codebase (so it will be present in 9.0); that allows you to write IR with scalable vector types, but there's no backend able to generate code for it yet, and as you mention no support for stepvector (or vscale). Arm will start upstreaming those soon. -Graham > On 1...

...sion and > vector-length multiplication)? > Or, do you think the EVL proposal would need modification to > effectively support this (by adding a element group size argument to > EVL intrinsics or something)? We could untie the mask length from the data length:   %result = call <scalable 4 x float> @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4 x float> %y, <scalable 1 x i1> %M, i32 %L) would then indicate the the mask %M applies to groups of "4 / 1" float elements. - Simon > Jacob Lifshay > > On Thu, Jan 31, 2019, 07:58 Sim...

...treault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > > > I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take (isa<VectorType>(Ty) && !isa<FixedVectorType>(Ty)) to mean “is a scalable vector”. This is both more...

I had a phone conversation yesterday with Graham, Francesco, and Kristof. There is one more reason to go with the native type change: ARM has already written the code with the SV types, and they have patches ready to be reviewed and integrated in LLVM. As I don't want to stand in the way of getting SVE in LLVM as soon as possible, I will also support the integration of the existing patches