search for: scalablity

On 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

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

Hi, Now that Sander has committed enough MC support for SVE, here's an updated RFC for variable length vector support with a set of 14 patches (listed at the end) to demonstrate code generation for SVE using the extensions proposed in the RFC. I have some ideas about how to support RISC-V's upcoming extension alongside SVE; I'll send an email with some additional comments on

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>

On Thu, Feb 7, 2019, 09:21 Simon Moll <moll at cs.uni-saarland.de> wrote: > > On 2/7/19 6:08 PM, David Greene wrote: > > Jacob Lifshay <programmerjake at gmail.com> writes: > > > >> So it would be handy for the vector length on evl intrinsics to be in > >> units of the mask length so we don't have to pattern match a division > >> in the

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

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 >

On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Simon Moll <moll at cs.uni-saarland.de> writes: > > > 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,

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 several loop-vectorization

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

Jacob Lifshay <programmerjake at gmail.com> writes: > So it would be handy for the vector length on evl intrinsics to be in > units of the mask length so we don't have to pattern match a division > in the backend. We could have 2 variants of the vector length > argument, one in terms of the data vector and one in terms of the mask > vector. we could legalize the mask

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 that inherits from

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

On Mon, 4 Feb 2019 at 22:04, Simon Moll <moll at cs.uni-saarland.de> wrote: > On 2/4/19 9:18 PM, Robin Kruppe wrote: > > > > On Mon, 4 Feb 2019 at 18:15, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Simon Moll <moll at cs.uni-saarland.de> writes: >> >> > You are referring to the sub-vector sizes, if i am

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 13 Jul 2019, at 14:32, Alex Susu via

Hi, On 1/31/19 11:20 PM, Jacob Lifshay wrote: > We're in-progress designing a RISC-V extension > (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) > that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x float>> > where each predicate bit masks out a whole short vector. We're using > this extension

Nicolai, My plan is to remove getNumElements() as soon as possible. Hopefully within the next few weeks. I just made a patch on my machine that marks it deprecated, and it generates a ton of warnings. Given that some build bots build with -Werror, I don't think we can mark it deprecated unless all the usages are first removed. It occurs to me now that it might be good to mark it

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