similar to: [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths

Hi, Are there any objections to going ahead with this? If not, we'll try to get the patches reviewed and committed after the 7.0 branch occurs. -Graham > On 2 Jul 2018, at 10:53, Graham Hunter <Graham.Hunter at arm.com> wrote: > > Hi, > > I've updated the RFC slightly based on the discussion within the thread, reposted below. Let me know if I've missed

On 07/30/2018 05:34 AM, Chandler Carruth wrote: > I strongly suspect that there remains widespread concern with the > direction of this, I know I have them. > > I don't think that many of the people who have that concern have had > time to come back to this RFC and make progress on it, likely because > of other commitments or simply the amount of churn around SVE related >

In the RISC-V V extension, there is no upper limit to the size vector registers can be in a future CPU. (Formally, the upper limit is at least 2^31 bytes) Generic code can enquire the size, 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>

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

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 }

Hi Graham, Thanks for your kind explanation. There was internal discussion about it. If possible, can you let me know the Clang/LLVM CodeGen patches for the vector type on phabricator please? I would like to check what kinds of the restrictions the type causes on Clang/LLVM. Thanks, JinGu Kang ________________________________ From: Graham Hunter <Graham.Hunter at arm.com> Sent: 28 May

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

Hi Renato, Sorry for the delay in responding. We've been busy rethinking some of our changes after the feedback we've received thus far (particularly from the devmeeting). The incremental patches will use our revised design(which should be less invasive), and I'll be updating our document to match. On 16/11/2016, 12:46, "Renato Golin" <renato.golin at linaro.org>

Hi Renato, Thanks for taking a look. Answers inline below, let me know if I've missed something out. -Graham > On 5 Jun 2017, at 17:55, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Graham, > > Just making sure some people who voiced concerns are copied + cfe-dev. > > On 1 June 2017 at 15:22, Graham Hunter via llvm-dev > <llvm-dev at

Hi, Here's the updated RFC for representing scalable vector types and associated constants in IR. I added a section to address questions that came up on the recent patch review. -Graham =================================================== Supporting Scalable Vector Architectures in LLVM IR =================================================== ========== Background ========== *ARMv8-A

Hi Graham, One high level comment without reading the patchset too much - it seems 'vscale' in particular could be just as easy to implement as an intrinsic, which would be a less invasive patch. Is there a reason you didn't go down the intrinsic route? James On Thu, 24 Nov 2016 at 15:39, Graham Hunter via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Paul

Hi David, Responses below. -Graham On 11 Jun 2018, at 22:19, David A. Greene <dag at cray.com<mailto:dag at cray.com>> wrote: Graham Hunter <Graham.Hunter at arm.com<mailto:Graham.Hunter at arm.com>> writes: ======== 1. Types ======== To represent a vector of unknown length a boolean `Scalable` property has been added to the `VectorType` class, which indicates that

Hi David, Thanks for taking a look. > On 5 Jun 2018, at 16:23, dag at cray.com wrote: > > Hi Graham, > > Just a few initial comments. > > Graham Hunter <Graham.Hunter at arm.com> writes: > >> ``<scalable x 4 x i32>`` and ``<scalable x 8 x i16>`` have the same number of >> bytes. > > "scalable" instead of "scalable

On 26 November 2016 at 11:49, Paul Walker <Paul.Walker at arm.com> wrote: > Related to this I want to push this and related conversations in a different direction. From the outset our approach to add SVE support to LLVM IR has been about solving the generic problem of vectorising for an unknown vector length and then extending this to support predication. With this in mind I would

Hi Graham, I'll look into the patches next, but first some questions after reading the available white papers on the net. On 24 November 2016 at 15:39, Graham Hunter <Graham.Hunter at arm.com> wrote: > This complex constant represents the runtime value of `n` for any scalable type > `<n x m x ty>`. This is primarily used to increment induction variables and > generate

On Mon, Nov 28, 2016 at 7:37 AM Paul Walker via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That is my intention with the stepvector patch ( > https://reviews.llvm.org/D27105). You can see that the interface is > common but for non-scalable vectors the result is its equivalent > ConstantVector. Once an agreed form is available > LoopVectorize::getStepVector can be

Currently, for scalable vectors, only splat shuffles are allowed; we're considering allowing more different kinds of shuffles. The issue is, essentially, that a shuffle mask is a simple list of integers, and that isn't enough to express a scalable operation. For example, concatenating two fixed-length vectors currently looks like this: shufflevector <2 x i32> %v1, <2 x i32>

On 27 November 2016 at 13:59, Paul Walker <Paul.Walker at arm.com> wrote: > Thanks Renato, my takeaway is that I am presenting the design out of order. So let's focus purely on the vector length (VL) and ignore everything else. For SVE the vector length is unknown and can vary across an as yet undetermined boundary (process, library....). Within a boundary we propose making VL a

On 5 June 2018 at 16:23, <dag at cray.com> wrote: > 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. Same here. > If we went the ConstantExpr route and added ConstantExpr support to > ScalarEvolution, then SCEVs

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