[llvm-dev] [RFC] Supporting ARM's SVE in LLVM

Graham Hunter via llvm-dev
Tue, 22 Nov 2016 14:49:18 -0000

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