similar to: Scalable Vector Types in IR - Next Steps?

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

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

On Wed, 13 Mar 2019 at 13:57, Graham Hunter <Graham.Hunter at arm.com> wrote: > I did ask them to post their arguments on the list, but I guess they've been busy for the last month (or forgot about it). Who is "them" and who will write up a proposal / RFC on the use of intrinsics for both lowering and vectorisation? It goes without saying that those discussions should have

Disclaimer: I’m only speaking for myself, not Apple. This is really disappointing. Resorting to multi-versioned fixed length vectorization isn’t a solution that’s competitive with the native VLA support, so it doesn’t look like a credible alternative suggestion (at least not without elaborating it on the mailing list). Without a practical alternative, it’s essentially saying “no” to a whole class

Graham Hunter <Graham.Hunter at arm.com> writes: > We (Arm) have had more off-line discussions with some members of the > community and they have expressed some reservations on adding scalable > vectors as a first class type. They have proposed an alternative to > enable support for C-level intrinsics and autovectorization for SVE. Can we get a summary of those discussions?

Agreed with both! Furthermore, any temporary solution will have to be very similar to what we expect to see natively, or the transition to native may never happen. On Wed, 13 Mar 2019, 18:55 Finkel, Hal J., <hfinkel at anl.gov> wrote: > On 3/13/19 1:45 PM, Amara Emerson via llvm-dev wrote: > > Disclaimer: I’m only speaking for myself, not Apple. > > > > This is really

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

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

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 }

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 Fri, 15 Mar 2019 at 16:50, James Y Knight <jyknight at google.com> wrote: >> Ie. the current series is already dead, no matter what we do > > But this last statement seems odd. So far, there looks to be a fairly good consensus from a number of experienced llvm developers that the approach seems like a good idea, both on this thread, and from skimming the earlier threads you

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

On Wed, Mar 27, 2019 at 6:46 PM Chandler Carruth <chandlerc at gmail.com> wrote: > Using intrinsics and an opaque type, IMO, makes the most sense as a pass-through mechanism for allowing very limited usage without investing in any significant mid-level analysis or transformation awareness. Ok, so if there are just a few passes to be amended, we may want to go the opaque type route. Can

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

On Tue, Mar 19, 2019 at 4:11 AM Graham Hunter <Graham.Hunter at arm.com> wrote: > Hi Eric and Chandler, > > I appreciate your concerns; I don't think the impact will be that great, > but then it's > rather easy for me to keep SVE in mind when working on other parts of the > codebase > given how long I've spent working on it. > > Are there any

On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 3/15/19 10:58 AM, David Greene wrote: >> > Renato Golin <rengolin at gmail.com> writes: >> > >> >> On Fri, 15 Mar 2019 at