[llvm-dev] [RFC] Supporting ARM's SVE in LLVM
James Molloy via llvm-dev
llvm-dev at lists.llvm.org
Thu Nov 24 12:49:38 PST 2016
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 Walker has now uploaded the first set of IR support patches to
> phabricator, which use our revised design. We managed to remove the need
> for new instructions for basic scalable vectorization in favor of adding
> two new constant classes; here's a subset of the revised documentation
> describing just those constants:
>
> ## *vscale*
>
> ### Syntax:
>
> > `vscale`
>
> ### Overview:
>
> 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 offsets.
>
> ### Interface:
>
> ```cpp
> Constant *VScaleValue::get(Type *Ty);
> ```
>
> ### Example:
>
> The following shows how an induction variable would be incremented for a
> scalable vector of type `<n x 4 x i32>`.
>
> ```llvm
> %index.next = add nuw nsw i64 %index, mul (i64 vscale, i64 4)
> ```
>
> ## *stepvector*
>
> ### Syntax:
>
> > `stepvector`
>
> ### Overview:
>
> This complex constant represents the runtime value of a vector of
> increasing
> integers in the arithmetic series:
>
> > `<0, 1, 2, ... num_elements-1>`
>
> This is the basis for a scalable form of vector constants. Adding a splat
> changes the effective starting point, and multiplying changes the step. The
> main uses for this are:
>
> * Predicate creation using vector compares for fully predicated loops (see
> also:
> [*propff*](#propff), [*test*](#test)).
> * Creating offset vectors for gather/scatter via `getelementptr`.
> * Creating masks for `shufflevector`.
>
> For the following loop, a `stepvector` constant would be added to a splat
> of the
> loop induction variable to create the data vector to store:
>
> ```cpp
> unsigned a[LIMIT];
>
> for (unsigned i = 0; i < LIMIT; i++) {
> a[i] = i;
> }
> ```
>
> ### Interface:
>
> ```cpp
> Constant *StepVectorValue::get(Type *Ty);
> ```
>
> ### Example:
>
> The following shows the construction of a scalable vector of the form
> <start, start-2, start-4, ...>:
>
> ```llvm
> %elt = insertelement <n x 4 x i32> undef, i32 %start, i32 0
> %widestart = shufflevector <n x 4 x i32> %elt, <n x 4 x i32> undef, <n x
> 4 x i32> zeroinitializer
> %step = insertelement <n x 4 x i32> undef, i32 -2, i32 0
> %widestep = shufflevector <n x 4 x i32> %step, <n x 4 x i32> undef, <n x
> 4 x i32> zeroinitializer
> %stridevec = mul <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'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> wrote:
>
> > This email is long and hard to read. I'm not surprised no one
> replied
> > yet. I think your PDF attached is a good start away from the
> > complexity, but we're not going to get far if we try to do things in
> > one step.
>
> > Based on your repository, the number of changes is so great, and the
> > changes so invasive, that we really should look back at what we need
> > to do, one step at a time, and only perform the refactoring changes
> > that are needed for each step.
>
> We don't intend to do this all in one go; we fully expect that we'll
> need to refactor a few times based on community feedback as we
> incrementally add support for scalable vectors.
>
> > > * This is a warts-and-all release of our development tree, with
> plenty of TODOs and unfinished experiments
> > > * We haven't posted our clang changes yet
> >
> > I don't mind FIXMEs or TODOs, but I did see a lot of spurious name
> > changes, enum value moves (breaking old binaries) and a lot of new
> > high-level passes (LoopVectorisationAnalysis) which will need a long
> > review on their own before we even start thinking about SVE.
> >
> > I recommend you guys separate the refactoring from the
> implementation
> > and try to upstream the initial and uncontroversial refactorings
> (name
> > changes, etc), as well as move out the current functionality into
> new
> > passes, so then you can extend for SVE as a refactoring, not
> > move-and-extend in the same pass.
>
> So our highest priority is getting basic support for SVE into the
> codebase (types, codegen, assembler/disassembler, simple vectorization);
> after that is in, we'll be happy to discuss our other changes like
> separating out loop vectorization legality, controlling loops via
> predication, or adding search loop vectorization.
>
> > We want to minimise the number of changes, so that we can revert
> > breakages more easily, and have a steady progress, rather than a
> > break-the-world situation.
>
> Same for us. The individual patches will be relatively small, this
> repo was just for context if needed when discussing the smaller patches.
>
> > Finally, *every* test change needs to be scrutinised and guaranteed
> to
> > make sense. We really dislike spurious test changes, unless we can
> > prove that the test was unstable to being with, in which case we
> > change it to a better test.
>
> Yep, makes sense.
>
> Thanks,
>
> -Graham
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161124/d5b78471/attachment.html>
More information about the llvm-dev
mailing list