similar to: RFC: AArch64 SVE Assembler/Disassembler patches

Thanks Alex! We thought it would be good to start sharing the more mechanical parts of our SVE work, separate from more involved topics like IR and Codegen. Hopefully the assembler/disassembler patches will give some visibility into the available instructions (other than just pointing to specification/documentation). Most of these assembler/disassembler patches are functionally quite simple, the

Hello, I am following up on the issue discussed at the SVE meeting, Sander mentioned that there were some patterns missing from SVE CodeGen for floating point operations, but I was unable to identify them. He mentioned something about looking at the ISelLowering for AArch64 to identify them, so if there is any information of that regard it would be greatly appreciated so we can contribute with

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

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

Hello. I would like to build some examples for ARM SVE. I see the support for SVE is available in the AArch64 back end of the latest LLVM. So I thought of using the latest LLVM distribution (revision 352287 from Jan 2019) and not rely on the ARM HPC compiler from https://developer.arm.com/products/software-development-tools/hpc/arm-cpp-compiler. Following

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

Hello, Just bringing to people's attention that we organise a bi-weekly sync-up call to discuss and collaborate on upstream support for scalable vectors and SVE/SVE2 CodeGen support in LLVM. The meetings are held every other Thursday, with the next meeting tomorrow (April 2nd) at 3pm GMT / 7am PST. The invite and agenda for tomorrow's meeting (including links to minutes from previous

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

In the RISC-V V extension, there is no upper limit to the size vector registers can be in a future CPU. (Formally, the upper limit is at least 2^31 bytes) Generic code can enquire the size, dynamically allocate space, and transparently save and restore the contents of a vector register or registers. On Fri, May 24, 2019 at 11:28 AM JinGu Kang via llvm-dev <llvm-dev at lists.llvm.org>

Hi David, >>> The name "getSizeExpressionInBits" makes me think that a Value >>> expression will be returned (something like a ConstantExpr that uses >>> vscale). I would be surprised to get a pair of integers back. Do >>> clients actually need constant integer values or would a ConstantExpr >>> sufffice? We could add a ConstantVScale or

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

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

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>

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

Hi, > On 6 Jun 2018, at 17:36, David A. Greene <dag at cray.com> wrote: > > Graham Hunter via llvm-dev <llvm-dev at lists.llvm.org> writes: > >>> Ok, now I understand what you're getting at. A ConstantExpr would >>> encapsulate this computation. We alreay have "non-static-constant" >>> values for ConstantExpr like sizeof and

Hi all, It's been a while since we've given an update on scalable vector support in LLVM. Over the last 12 months a lot of work has been done to make LLVM cope with scalable vectors. This effort is now starting to bear fruit with LLVM gaining more capabilities, including an intrinsics interface for AArch64 SVE/SVE2, LLVM IR Codegen for scalable vectors, and several loop-vectorization

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>