Previously we can only lower arith.index_cast with 1-D vectors to LLVM. This change added the support for n-D vectors.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Conversion/ArithmeticToLLVM/ArithmeticToLLVM.cpp | ||
---|---|---|
137–143 | Can't this just be typeConverter->convertType(getElementTypeOrSelf(op.getIn().getType()) ? |
mlir/lib/Conversion/ArithmeticToLLVM/ArithmeticToLLVM.cpp | ||
---|---|---|
137–143 | getElementTypeOrSelf can only extracts one level of a ShapedType. |
mlir/lib/Conversion/ArithmeticToLLVM/ArithmeticToLLVM.cpp | ||
---|---|---|
137–143 | I know, and the original type op.getIn().getType() is a single-level vector type because we can't nest vectors. The code does literally the same for targetElementType in line 135. |
mlir/lib/Conversion/ArithmeticToLLVM/ArithmeticToLLVM.cpp | ||
---|---|---|
137–143 | The op.getIn().getType() is vector types in this case. It's not the converted type. (The method you use is the converted type -- adaptor.getIn().getType(). As ftynse's suggestion, I think the typeConverter can handle the case? | |
145–146 | I think we can use getIntOrFloatBitWidth(). It looks cleaner to me. ... = targetElementType.getIntOrFloatBitWidth(); ... |
mlir/lib/Conversion/ArithmeticToLLVM/ArithmeticToLLVM.cpp | ||
---|---|---|
137–143 | Oh, I'm sorry, I misread the op.getIn() as adaptor.getIn(). I'm not familiar with rewrite, but will it be a case where the operand of arith.index_cast has been rewritten into another type with a different element type (e.g., extension)? Therefore the element type from op.getIn() and adaptor.getIn() are different. |
Can't this just be typeConverter->convertType(getElementTypeOrSelf(op.getIn().getType()) ?