similar to: [SVE][AArch64] Codegen for a scalable vector splat

Just spitballing... why not have a splat construct straight through LLVM? It would make the IR more readable, opposed to the insert+shuffle method. On Thu, Aug 29, 2019 at 19:06 Amara Emerson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 to a new node, we’d very likely do the same thing for GlobalISel and > move to a canonical spat representation for all targets. > >

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

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

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>

Hi, We've been working for the last two years on support for ARM's Scalable Vector Extension in LLVM, and we'd like to upstream our work. We've had to make several design decisions without community input, and would like to discuss the major changes we've made. To help with the discussions, I've attached a technical document (also in plain text below) to describe the

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 >

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

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

Hi All, First of all, I am not native English speaker. While reading BUILD_VECTOR related code, for example, PPCTargetLowering::LowerBUILD_VECTOR, I see "splat" here and there. Could someone explain what it is (does splat mean the same thing across the whole code base)? Besides, from my English dictionary, I don't know why we call such thing as "splat"... :p Regards,

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

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

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