Rename VectorOps.cpp `convertIntegerAttr` to `convertNumericAttr` and handle float attributes

[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

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, 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

[llvmbot]

@llvm/issue-subscribers-mlir-vectorops

Author: Jhalak Patel (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

func.func @<!-- -->from_elements() -&gt; vector&lt;1xi8&gt; {
    %cst = llvm.mlir.constant(0.0 : f8E4M3FN) : i8
    %v = vector.from_elements %cst : vector&lt;1xi8&gt;
    return %v : vector&lt;1xi8&gt;
}

As noted in the PR #149787 discussion, 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