similar to: [RFC] Refactor class hierarchy of VectorType in the IR

Hi, I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take

Nicolai, My plan is to remove getNumElements() as soon as possible. Hopefully within the next few weeks. I just made a patch on my machine that marks it deprecated, and it generates a ton of warnings. Given that some build bots build with -Werror, I don't think we can mark it deprecated unless all the usages are first removed. It occurs to me now that it might be good to mark it

Hi John, I’d like to address some points in your message. > Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types. My understanding is that the policy in LLVM development is that we do not let considerations for downstream and out-of-tree codebases affect the pace of development. The C++ API is explicitly unstable.

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

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 was playing with the Constant::getAllOnesValue() method and found that it doesn't handlesPointerTypes correctly. When receiving a "i32*" argument, it was returning with some big integer vector, such as <12113216 x i32>. When you call this method passing a PointerType, the following code is executed: 00152 VectorType *VTy = cast<VectorType>(Ty);00153 return

John, For the last several months, those of us working on the scalable vectors feature have been examining the codebase, identifying places where llvm::VectorType is used incorrectly, and fixing them. The fact is that there are many places where VectorType is correctly taken to be the generic “any vector” type. getNumElements may be being called, but it’s being called in accordance with the

Bringing this up on llvm-dev for more general attention. The problem here is two fold: (1) Reuse of enumeration values is just a major no-go. (2) I'm not sure why the existing vector types had to be killed completely. But something clearly has to be done here. This majorly affects e.g. Mesa. Joerg ----- Forwarded message from Joerg Sonnenberger via llvm-commits <llvm-commits at

Hi, Here's the updated RFC for representing scalable vector types and associated constants in IR. I added a section to address questions that came up on the recent patch review. -Graham =================================================== Supporting Scalable Vector Architectures in LLVM IR =================================================== ========== Background ========== *ARMv8-A

On Oct 14, 2008, at 11:02 AM, Duncan Sands wrote: > Hi Mon Ping, > >> I would like to make it illegal to GEP into a vector as I think it is >> cleaner and more consistent. Opinions? Comments? > > now that arrays are first class types, I think vectors should become > a subclass of ArrayType. This would get rid of a lot of duplicated > code, and also fix a bunch of

Hi, Now that Sander has committed enough MC support for SVE, here's an updated RFC for variable length vector support with a set of 14 patches (listed at the end) to demonstrate code generation for SVE using the extensions proposed in the RFC. I have some ideas about how to support RISC-V's upcoming extension alongside SVE; I'll send an email with some additional comments on

Hi Renato, Thanks for taking a look. Answers inline below, let me know if I've missed something out. -Graham > On 5 Jun 2017, at 17:55, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Graham, > > Just making sure some people who voiced concerns are copied + cfe-dev. > > On 1 June 2017 at 15:22, Graham Hunter via llvm-dev > <llvm-dev at

Hi, Are there any objections to going ahead with this? If not, we'll try to get the patches reviewed and committed after the 7.0 branch occurs. -Graham > On 2 Jul 2018, at 10:53, Graham Hunter <Graham.Hunter at arm.com> wrote: > > Hi, > > I've updated the RFC slightly based on the discussion within the thread, reposted below. Let me know if I've missed

Hi Chris, > I'm happy about factoring the code better, but a vectortype isn't an > arraytype (isa<ArrayType>(V) should be false). Maybe a common base > class (like sequential type) would be better? currently anything you can do with an array you can do with a vector. So from this functional viewpoint it would make sense to have a vector be an array with more stuff

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>

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 07/30/2018 05:34 AM, Chandler Carruth wrote: > I strongly suspect that there remains widespread concern with the > direction of this, I know I have them. > > I don't think that many of the people who have that concern have had > time to come back to this RFC and make progress on it, likely because > of other commitments or simply the amount of churn around SVE related >

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

Regarding the numerical value of the LLVMTypeKind enum, my understanding is that LLVM-C does not promise to maintain ABI compatability between versions. If I am mistaken, I can fix this issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, May 13, 2020 7:33 AM To: Joerg Sonnenberger <joerg at bec.de>; llvm-dev <llvm-dev