Issue |
159613
|
Summary |
Rename VectorOps.cpp `convertIntegerAttr` to `convertNumericAttr` and handle float attributes
|
Labels |
new issue
|
Assignees |
|
Reporter |
jhalakpatel
|
Following up on #158528, we need to handle type mismatches with float attributes. The current `convertIntegerAttr` function only handles integer attributes, but float attributes can also cause type inconsistencies during LLVM conversion.
## Example Type Mismatch
```mlir
func.func @from_elements() -> vector<1xi8> {
%cst = llvm.mlir.constant(0.0 : f8E4M3FN) : i8
%v = vector.from_elements %cst : vector<1xi8>
return %v : vector<1xi8>
}
```
As noted in the [PR #149787 discussion](https://github.com/llvm/llvm-project/pull/149787#issuecomment-3097981265), while users don't typically write `llvm.mlir.constant(0.0 : f8E4M3FN) : i8` manually, such constructs can arise during MLIR lowering passes and need to be handled correctly.
This crashes in the canonicalizer with the same assertion failure:
```
mlir::DenseElementsAttr mlir::DenseElementsAttr::reshape(mlir::ShapedType):
Assertion `newType.getElementType() == curType.getElementType() && "expected the same element type"' failed.
```
The issue occurs when `arith.constant 0.0 : f8E4M3FN` gets processed by `convert-arith-to-llvm`, creating a mismatch between the result type (`i8`) and attribute element type (`f8E4M3FN`).
## Solution
1. **Rename** `convertIntegerAttr` to `convertNumericAttr` to reflect broader scope
2. **Add assertion** to ensure the input attribute is either an integer or float attribute
3. **Extend logic** to handle float attribute conversion using the same type conversion approach
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs