search for: seriesvector

...9;m assuming the vectorizer will *have* to learn about the compulsory predication and build those vectors, or the back-end will have to handle them, and it can get ugly. >> %const_vec = <n x 4 x i32> @llvm.sve.constant_vector(i32 %start, i32 %step) > > This intrinsic matches the seriesvector instruction we original proposed. However, on reflection we didn't like how it allowed multiple representations for the same constant. Can you expand how this allows multiple representations for the same constant? This is a series, with a start and a step, and will only be identical to anoth...

...ecause the back-end *must* guarantee it will be a constant within its boundaries and fail otherwise. That's up to the SVE code-generator to add enough SVE-specific instructions to get that right. > shufflevector <n x 4 x i32> %a, <n x 4 x i32> undef, <n x 4 x i32> seriesvector ( sub (i32 VL, 1), i32 -1) > > Firstly I'll highlight the use of seriesvector is purely for brevity, let's ignore that debate for now. Our concern is that not treating VL as a Constant means sub and seriesvector are no longer constant and are likely to be hoisted away from the shuffl...

...within the loop vectorizer. ### IRBuilder Interface: ```cpp Value *CreateElementCount(Type *Ty, Value *V, const Twine &Name = ""); ``` ### Fixed-Width Behaviour: A constant with the value of `Min` is created. ### SelectionDAG: See [*ISD::ELEMENT_COUNT*](#isdelementcount). ## *seriesvector* ### Syntax: `<result> = seriesvector <ty> <v1>, <v2> as <n x m x ty>` ### Overview: This instruction returns a vector of type `<n x m x ty>` with elements forming the arithmetic series: `elt[z] = v1 + z * v2` where `z` is the element index and `<ty>`...

...ef, <i32 3, i32 2, i32 1, i32 0> > > Throughout the IR and into code generation the intention of this instruction is clear. Now turning to scalable vectors the same operation becomes: > > shufflevector <n x 4 x i32> %a, <n x 4 x i32> undef, <n x 4 x i32> seriesvector ( sub (i32 VL, 1), i32 -1) > > Firstly I'll highlight the use of seriesvector is purely for brevity, let's ignore that debate for now. Our concern is that not treating VL as a Constant means sub and seriesvector are no longer constant and are likely to be hoisted away from the shuffl...

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

On 27 November 2016 at 16:51, Amara Emerson <amara.emerson at gmail.com> wrote: > There is nothing to stop other targets from using > stepvector/seriesvector. In fact for wide vector targets, often the IR > constant for representing a step vector is explicitly expressed as > <i32 0, i32 1, i32 2..> and so on (this gets really cumbersome when > your vector length is 512bits for example). That could be replaced by > a single "stepve...

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

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