search for: scalablevectortype

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 (isa<VectorType>(Ty) && !isa<FixedVectorType>(Ty)) to mean "is a scalable vector". This is both more...

...treault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 (isa<VectorType>(Ty) && !isa<FixedVectorType>(Ty)) to mean “is a scalable vector”. This is both more verbose, a...

...d length vectors, the user can call FixedVectorType::get() to directly get an instance of FixedVectorType, and their code can remain largely unchanged from how it was prior to the introduction of scalable vectors. At this time, there exists no use case that is only valid for scalable vectors, so no ScalableVectorType is being added. With this change, in generic code it is now impossible to accidentally call getNumElements() on a scalable vector. If a user tries to pass a scalable vector to a function that expects a fixed length vector, they will encounter a compilation failure at the site of the...

...ned VectorType::getNumElements()`. In March this year, Christopher Tetreault took on the monumental task to distinguish vector types in the codebase by modifying the type hierarchy for VectorType (http://lists.llvm.org/pipermail/llvm-dev/2020-March/139811.html). Chris added the FixedVectorType and ScalableVectorType classes and worked to deprecate `unsigned VectorType::getNumElements()`, because that method is only relevant in the context of FixedVectorType. In our meetings we discussed a deprecation cycle so that downstream projects can adapt to the new changes. As of August 31st, that method was marked depre...

...ment in upstream. 3. The process for completing the changes would be much easier if we use the types I propose. The compiler can tell you if you’re using getNumElements() on a potentially scalable vector. The compiler cannot tell you that SomeFixedVector->getElementCount().Scalable and isa<ScalableVectorType>(SomeFixedVector) are always false. Additionally, for those who disagree that the LLVM developer policy is to disregard the needs of downstream codebases when making changes to upstream, I submit that not throwing away months of work by everybody working to fix the codebase to handle scalabl...

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

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

...d length vectors, the user can call FixedVectorType::get() to directly get an instance of FixedVectorType, and their code can remain largely unchanged from how it was prior to the introduction of scalable vectors. At this time, there exists no use case that is only valid for scalable vectors, so no ScalableVectorType is being added. With this change, in generic code it is now impossible to accidentally call getNumElements() on a scalable vector. If a user tries to pass a scalable vector to a function that expects a fixed length vector, they will encounter a compilation failure at the site of the bug, rather tha...

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