search for: fixedvectortyp

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

...implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from SequentialType and VectorType. VectorType would no longer inherit from SequentialType, instead directly inheriting from Type. After this change, it will be statically impossible to accidentally call SequentialType::getNumElements() via a VectorType pointer. Background:...

...easier if getNumElements didn't just suddenly go away. I think the -Werror build bots would prevent most people from re-introducing it, we would just have to be very vigilant to ensure that nobody un-deprecates it. Since most usages of getNumElements() are either easy to fix (by casting to FixedVectorType), or likely are causing miscompilation, I would prefer to keep the amount of time it remains as short as possible. What do you think would be a reasonable period of time for it to be deprecated? 2 weeks? I would also like to add that assuming you have integrated https://reviews.llvm.org/rG2dea...

...is explicitly unstable. I maintain a downstream fork of LLVM myself, so I know the pain that this is causing because I get to fix all the issues in my internal codebase. However, the fix for downstream codebases is very simple: Just find all the places where it says VectorType, and change it to say FixedVectorType. > … by having the VectorType type semantically repurposed out from under them. The documented semantics of VectorType prior to my RFC were that it is a generalization of all vector types. The VectorType contains an ElementCount, which is a pair of (bool, unsigned). If the bool is true, then...

...s very easy to misuse, so I don’t blame those people. > Are you actually auditing and testing them all to work for scalable vector types, or are you just fixing the obvious compile failures? Everywhere that VectorType::getNumElements() is being called, we are either changing the code to cast to FixedVectorType, or we are updating the code to handle scalable vectors correctly. If the call site does not have test coverage with scalable vectors, this test coverage is being added. Even for obviously correct transformations such as `VectorType::get(SomeTy, SomeVecTy->getNumElements())` -> `VectorType::...

...I was very easy to misuse, so I don’t blame those people. Are you actually auditing and testing them all to work for scalable vector types, or are you just fixing the obvious compile failures? Everywhere that VectorType::getNumElements() is being called, we are either changing the code to cast to FixedVectorType, or we are updating the code to handle scalable vectors correctly. If the call site does not have test coverage with scalable vectors, this test coverage is being added. Even for obviously correct transformations such as `VectorType::get(SomeTy, SomeVecTy->getNumElements())` -> `VectorType::...

...ace alongside `unsigned 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...

Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t

...v] [llvm-commits at lists.llvm.org: Re: [llvm] 2dea3f1 - [SVE] Add new VectorType subclasses] Agreed. Those llvm-c changes are wrong, and compatibility needs to be maintained for the numeric values at minimum. Probably also would be a good idea to make LLVMVectorTypeKind a deprecated alias for LLVMFixedVectorTypeKind. On Wed, May 13, 2020 at 9:11 AM Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: 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. (...

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