similar to: Compile for ARM SVE with the latest LLVM

Renato et al. In the meantime, is there an out of tree branch I mean, other than LLVM trunk so I can test how much I can SVE vectorize my code with it? Arm seemed to gave taken down the GitHub branch for sometime. On Wed, Sep 11, 2019 at 20:41 Renato Golin <rengolin at gmail.com> wrote: > On Wed, 11 Sep 2019 at 06:13, Itaru Kitayama via llvm-dev > <llvm-dev at lists.llvm.org>

On 27 November 2016 at 13:59, Paul Walker <Paul.Walker at arm.com> wrote: > Thanks Renato, my takeaway is that I am presenting the design out of order. So let's focus purely on the vector length (VL) and ignore everything else. For SVE the vector length is unknown and can vary across an as yet undetermined boundary (process, library....). Within a boundary we propose making VL a

Hi, I'm still seeing the same ie trying to produce SVE instructions but resulted in NEONs with Clang as of Sep. 10th. http://lists.llvm.org/pipermail/llvm-dev/2019-March/130788.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190910/100290f6/attachment.html>

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

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 }

Hi, I am extending LLVM for HPC applications. As one of them, I am trying to make MachinePipeliner available on AArch64 + Scalable Vector Extension environment. MachinePipeliner is currently used only by Hexagon CPU. Since it is a very portable implementation, I think that it will actually work just by adding a little code for many CPUs(See Code [2]). The current MachinePipeliner is written on

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

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

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

Hi all, Several people have expressed interest in having regular sync-up calls to follow the progress of ARM SVE/SVE2 support in LLVM. With this effort picking up steam and multiple people contributing patches, regular sync-up calls would provide a platform to coordinate our efforts. Items to discuss in these sync-up calls would include: - SVE/SVE2 CodeGen support - Adding support for C/C++

Thanks to all who attended last week's SVE/SVE2 sync-up meeting! The next meeting will be on Thursday, January 9th, at 5pm GMT / 9am PST. I've created the agenda for the next meeting here: https://docs.google.com/document/d/17GqhBZaADtnDlDL3L4wWqcMd0qvfzB-VEe_ntodgYjA (If you want to attend, please add your name, email and organisation to the list referenced in the document above so I

Hi, Probably a lot of you are attending interesting talks at LLVM Dev meeting this week, so I hope this message isn't completely lost in all the excitement. In the past month we have carved off our changes to LLVM's assembler/disassembler that implement the AArch64 SVE instruction set [1]. These changes are split these up into individual patches that purely focus on the assembler and

On 27 November 2016 at 16:10, Amara Emerson <amara.emerson at gmail.com> wrote: > No. Let's make one thing clear now: we don't expect the VL to be > changed on the fly, once the process is started it's fixed. Otherwise > things like stack frames with SVE objects will be invalid. This then forbids different lengths on shared objects, which in turn forces all objects in

On 28 November 2016 at 01:43, Paul Walker <Paul.Walker at arm.com> wrote: > Reconsidering the above loops with this type system leads to IR like: > > (1) <n x 4 x i32> += zext <n x 4 x i8> as <n x 4 x i32> ; bigger_type=i32, smaller_type=i8 > (2) <n x 16 x i8> += <n x 16 x i8> Hi Paul, I'm with Mehdi on this... these examples

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

Hi, I would like to restart the conversation regarding adding SVE support to LLVM. This time I am framing things from the code generation point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding

On Tue, Oct 1, 2019 at 8:08 AM Robin Kruppe <robin.kruppe at gmail.com> wrote: > > Hello Jacob and Luke, > > First off, even if a dynamically changing vscale was truly necessary > for RVV or SV, this thread would be far too late to raise the question. > That vscale is constant -- that the number of elements in a scalable > vector does not change during program execution

I'm sorry.. may I interrupt for a minute and try to grok things for a bit different angle.. While the VL can vary.. in practice wouldn't the cost of vectorization and width be tied more to the hardware implementation than anything else? The cost of vectorizing thread 1 vs 2 isn't likely to change? (Am I drunk and mistaken?) If the above holds true then the the length would be only

On Tue, Oct 1, 2019 at 11:08 AM Graham Hunter <Graham.Hunter at arm.com> wrote: > Hi Luke, hi graham, thanks for responding in such an informative fashion. > > On 1 Oct 2019, at 09:21, Luke Kenneth Casson Leighton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > typedef vec4 float[4]; // SEW=32,LMUL=4 probably > > static vec4 globalvec[1024]; // vscale ==

On 28 November 2016 at 09:15, Alex Bradbury <asb at asbradbury.org> wrote: > The RISC-V vector proposal is still in the development stage, but it > will inevitably be vector length agnostic much like Hwacha. Krste gave > a talk about his proposal for the 'V' extension last year > <https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf> >