[Mlir-commits] [mlir] [mlir][arith.constant]Fix element type of the dense attributes in target attributes to be consistent with result type in LLVM::detail::oneToOneRewrite() (PR #149787)

Mengmeng Sun llvmlistbot at llvm.org
Mon Jul 21 09:09:39 PDT 2025


MengmSun wrote:

> As a general comment, I don't think mixing `llvm.mlir.constant` and operations like `vector.shape_cast` makes sense, and since `llvm.mlir.constant` allows for a type/attribute mismatch (to my knowledge), there might not be anything to fix here.

I don't think mixing is illegal. `vector.shape_cast` is lowered from our defined ops. 
In the previous [#133988]( https://github.com/llvm/llvm-project/pull/133988) the point is if `llvm.mlir.constant` allows for a type/attribute mismatch. If it allows, in my understanding, `vector.shape_cast` should consider this case instead of thinking the element type of the dense attributes is consistent with the result type [here](https://github.com/llvm/llvm-project/blob/2aa1e54fa1ff7f7c347e7108fe8650e94014c941/mlir/lib/Dialect/Vector/IR/VectorOps.cpp#L6000).

```cpp
// shape_cast(constant) -> constant
  if (auto splatAttr =
          llvm::dyn_cast_if_present<SplatElementsAttr>(adaptor.getSource()))
    return splatAttr.reshape(getType());
```
 So I think modifying this part is more reasonable. It's not maintaining more codes for incorrect codes. Instead, it categorizes the possible cases that may be encountered with `shape_cast(constant)->constant`.


https://github.com/llvm/llvm-project/pull/149787


More information about the Mlir-commits mailing list