search for: somevecty

...e 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::get(SomeTy, SomeVecTy->getElementCount())`, I have been required in code review to provide test coverage. We are taking this seriously. > “Vector” has a traditional and dominant meaning as a fixed-width SIMD type, and the fact that you’ve introduced...

...e 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::get(SomeTy, SomeVecTy->getElementCount())`, I have been required in code review to provide test coverage. We are taking this seriously. “Vector” has a traditional and dominant meaning as a fixed-width SIMD type, and the fact that you’ve introduced a gen...

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.