search for: d27105

...t;n x 4 x i32> stepvector, %widestep > %finalvec = add <n x 4 x i32> %widestart, %stridevec > ``` > > > > > Current patch set: > https://reviews.llvm.org/D27101 > https://reviews.llvm.org/D27102 > https://reviews.llvm.org/D27103 > https://reviews.llvm.org/D27105 > > -Graham > > > > On 22/11/2016, 14:49, "Graham Hunter via llvm-dev" < > llvm-dev at lists.llvm.org> wrote: > > Hi Renato, > > Sorry for the delay in responding. We've been busy rethinking some of > our changes after the feedback we&...

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 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 converted to become compatible with > scalable vectors very easily, albeit being only a small...

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