search for: sve

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

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> wrote: > > Hi, &gt...

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

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++ intrinsics interf...

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

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&g...

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 disassembler and have no link to the IR (yet). We would like to start sharing these patches with upstream LLVM. I have made a best effort to split these changes into small, manageab...

...<scalable 1 x <ty>>, since there may only be one element in the actual hardware vector at runtime. The same restriction applies to a <1 x <ty>>. This is why we have a minimum number of lanes in addition to the scalable flag so that we can concatenate and split vectors, since SVE registers have the same number of bytes and will therefore decrease the number of elements per register as the element type increases in size. If you want to extract something other than the first part of a vector, you need to add offsets based on a calculation from vscale (e.g. adding vscale * (m...

...tep after the vector loop body, doing a tree reduction across all the lanes. This has multiple disadvantages in being complex and difficult to generate for other passes in LLVM and front-ends. The reduction using shuffles then have to be matched in the backend. For ARM’s Scalable Vector Extensions (SVE), there are some more fundamental reasons that requires us to move away from this approach; 1) As our vector lengths are unknown at compile time (and also not a power of 2), we cannot generate the same reduction IR pattern as other targets. We need a direct IR representation of the reduction in o...

...ketizer Since implementations using only Instruction itineraries without DFAPacketizer are possible, I don't think that I can use TargetSchedModel::hasInstrItineraries to select the execution path. Personally, I think that implementation of (b) is better. Also, if predicated instructions like SVE are available, prologue and epilogue code generation using predicated execution as shown in the reference[1] may be possible. In this case, if we choose the implementation of (b) and it is possible to override SwingSchedulerDAG::generatePipelinedLoop, I think that it can easily be extended. Commen...

...scv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf> > and I'm looking forward to his update at the RISC-V Workshop this > Wednesday, not least because I'm hoping he'll have done my homework > for me and contrast his proposal to what is publicly known about SVE. Thanks! This is really helpful! > The proposal includes a vsetvl instruction (slide 20) which returns > the minimum of the hardware vector length and requested vector length. I haven't seen a similar instruction in SVE yet, but the compulsory predicate on all instructions kinda make...

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 the same OS to have the same length. Still a kernel option (like VMA or page tables sizes), but not on a per-process thing. Like ARM's ABI, it only makes sense to go that far on...

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

Hi Amara, We also had some discussions on the SVE side of reductions on the main SVE thread, but this description is much more detailed than we had before. I don't want to discuss specifically about SVE, as the spec is not out yet, but I think we can cover a lot of ground until very close to SVE and do the final step when we get there. On 3...

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

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 meetings) can be found here: https://docs.google.com/document/d/...

...y 2019 10:46 To: JinGu Kang Cc: Joel Jones; Chris Lattner; Hal Finkel; Jones, Joel; dag at cray.com; Renato Golin; Kristof Beyls; Amara Emerson; Florian Hahn; Sander De Smalen; Robin Kruppe; llvm-dev at lists.llvm.org; mkuper at google.com; Sjoerd Meijer; Sam Parker; nd Subject: Re: [EXT] Re: [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths Hi JinGu, > Above vectorized loop does not need tail loop. I guess we could map the %mask.vec to predicate register as native register class on ISelLowering level. The conditional branch could also be mapped to 'whilexx' an...

...scalable vector type the result is a predicate vector of all true. > > More exactly, I don't care right now that the LoopVectorize pass generates scalable vector code. What I only want right now is that I give an LLVM IR program with scalable vector code (obtained normally from the ARM SVE LLVM compiler, built from the source code https://github.com/ARM-software/LLVM-SVE) > to my standard LLVM distro + scalable vector support and it is able to: > - parse the .ll LLVM IR program > - then generate assembly code for my Connex back end, which I plan to use...

...e process, for instance, as > a result of PGO or if some loops have less loop-carried dependencies > than others. > > The three important premises are: > > 1. The vectorizer still has the duty to restrict the vector length to > whatever makes it cope with the loop dependencies. SVE *has* to be > able to cope with that by restricting the number of lanes "per > access". > > 2. The cost analysis will have to assume the smallest possible vector > size and "hope" that anything larger will only mean profit. This seems > straight-forward enough....

...I guess we could map the %mask.vec to predicate register as native register class on ISelLowering level. The conditional branch could also be mapped to 'whilexx' and 'b.xxx on MIR level. In order to get vector type, we could calculate cost model for target as llvm's vectorizers. If SVE focuses on loop vectorization mainly, I am not sure why the scalarable vector type is needed... From my personal opinion, the VLA programming model could add ambiquity and complexity to compiler because it is not concrete type at compile time... I am not expert for SVE and VLA. I could miss somethi...