[PATCH] D77258: Clean up usages of asserting vector getters in Type

Christopher Tetreault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 8 16:52:17 PDT 2020


ctetreau marked an inline comment as done.
ctetreau added inline comments.


================
Comment at: mlir/lib/Conversion/StandardToLLVM/StandardToLLVM.cpp:1597
           auto splatAttr = SplatElementsAttr::get(
-              mlir::VectorType::get(
-                  {llvmVectorTy.getUnderlyingType()->getVectorNumElements()},
-                  floatType),
+              mlir::VectorType::get({(unsigned)cast<llvm::VectorType>(
+                                         llvmVectorTy.getUnderlyingType())
----------------
efriedma wrote:
> ctetreau wrote:
> > sdesmalen wrote:
> > > is the cast to `unsigned` needed?
> > VectorType::getNumElements() returns uint64_t, where Type::getVectorNumElements() returned unsigned. At least in visual studio, this results in an error due to a narrowing conversion.
> > 
> > I have no idea why this is, I can't imagine that we'd need 64 bits to express the number of vector lanes.
> Actually, I'm pretty sure it's actually "SequentalType::getNumElements()" returns a uint64_t.
> 
> We could consider changing that once I land the patch to kill SequentialType.
I added D77763 to change it. Most of the calls to this were through getVectorNumElements() anyways, which did the cast.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77258/new/

https://reviews.llvm.org/D77258





More information about the llvm-commits mailing list