search for: sve2

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 interface (...

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

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/17Gqh...

...ve-x22,-reserve-x23,-reserve-x24,-reserve-x25,-reserve-x26,-reserve-x27,-reserve-x28,-reserve-x3,-reserve-x4,-reserve-x5,-reserve-x6,-reserve-x7,-reserve-x9,-saphira,+sb,+sel2,-sha2,-sha3,-slow-misaligned-128store,-slow-paired-128,-slow-strqro-store,-sm4,-spe,+specrestrict,+ssbs,-strict-align,-sve,-sve2,-sve2-aes,-sve2-bitperm,-sve2-sha3,-sve2-sm4,-thunderx,-thunderx2t99,-thunderxt81,-thunderxt83,-thunderxt88,+tlb-rmi,-tpidr-el1,-tpidr-el2,-tpidr-el3,+tracev8.4,-tsv110,+uaops,-use-aa,+use-postra-scheduler,-use-reciprocal-square-root,+v8.1a,+v8.2a,+v8.3a,+v8.4a,+v8.5a,+vh,-zcm,-zcz,-zcz-fp,-zcz-fp-...

...n 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 prototypes that show the ability to vectorize with scalable VFs. Assuming not everyone is following this effort closely, people will undoubtably have seen some of the changes in the code-base around this, so here is a brief upda...

...using scalable vectors for RISC-V Vector extension in context of the EPI Project <https://www.european-processor-initiative.eu/accelerator/>. We earlier shared a demo of our prototype implementation  (https://repo.hca.bsc.es/epic/z/9eYRIF, see below) with the folks involved with LLVM SVE/SVE2 development. Since there was an interest in looking at the source code during the discussions in the subsequent LLVM SVE/SVE2 sync-up meetings, we are also publishing a public copy of our repository. It is available at https://repo.hca.bsc.es/gitlab/rferrer/llvm-epi and will sync with our ongo...

...include scalable vectors in consideration when thinking about it. Agreed. It would be very useful to think about a scalable vectors aware cost-model right from the beginning now that there is effort already underway to integrate it into VPlan. There was also a discussion around it in the latest SVE/SVE2 sync-up meeting and I think almost everyone was in agreement. The NEON vs RISCV register shadowing is interesting. It is true we mostly ignored 64-bit vectors in the vectoriser, but LLVM can still generate them with the (SLP) region vectoriser. IIRC, support for that kind of aliasing is not trivia...

...include scalable vectors in consideration when thinking about it. Agreed. It would be very useful to think about a scalable vectors aware cost-model right from the beginning now that there is effort already underway to integrate it into VPlan. There was also a discussion around it in the latest SVE/SVE2 sync-up meeting and I think almost everyone was in agreement. The NEON vs RISCV register shadowing is interesting. It is true we mostly ignored 64-bit vectors in the vectoriser, but LLVM can still generate them with the (SLP) region vectoriser. IIRC, support for that kind of aliasing is not trivia...

...needs to be used to generate code for scalable vectors. The second patch [2] adds the ISD::VSCALE node which, if supported by the target, can be materialised into an instruction that returns the runtime value for `vscale`. It can also be used to be folded into addressing modes, like needed for SVE/SVE2 reg+imm load/store instructions. I'm aware that Graham has discussed this before at previous dev meetings and that some had their reservations about exposing this as a Constant explicitly. But the reasons for doing so are because the value is inherently constant. If it is not constant, this wo...

...being utilised) than if vscale=16. If fixed-width/short vectors are more beneficial for some algorithm, I'd recommend using fixed-width vectors directly. It would be up to the target to lower that to the vector instruction set. For AArch64, this can be done using Neon (max 128bits) or with SVE/SVE2 using a 'fixed-width' predicate mask, e.g. vl4 for a predicate of 4 elements, even when the vector capacity is larger than 4. > would it be reasonable to assume that predication *always* is to be > used in combination with vscale? or is it the intention to > [eventually] be able...

Thanks @Robin and @Graham for giving some background on scalable vectors and clarifying some of the details! Apologies if I'm repeating things here, but it is probably good to emphasize the conceptually different, but complementary models for scalable vectors: 1. Vectors of unknown, but constant size throughout the program. 2. Vectors of changing size throughout the program. Where (2)

John, > This is not categorically true, no. When we make changes that require large-scale updates for downstream codebases, we do so because there’s a real expected benefit to it. For the most part, we do make some effort to keep existing source interfaces stable. While I’m at a loss to find a documented policy, I recall this thread