[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)

[James Newling]

newling wrote:

My preference would be to make the element type change illegal in the constant op, i.e. that 

```
%4 = llvm.mlir.constant(dense<0.000000e+00> : vector<192xf8E4M3FN>) : vector<192xi8>
```

is illegal (along the lines of this PR). One downside would be the textual form numerical values would no longer make sense. I don't have the context to know if this is a feasible restriction to place on the llvm constant op for all users.  


>  Actually under current mechanism any subsequent operations on it will expose this problem.

This suggests that the problem isn't specific to ShapeCast::fold, but could be a problem for any fold operation. Is that correct @MengmSun ?

> If the vector::ShapeCast folder (not canonicalizer) is hitting this bug, then we need to add guards to the folder to catch this sort of thing

It is the folder.  The original solution in https://github.com/llvm/llvm-project/pull/147691 actually does a good job -- it uses the element type of the original attribute instead of the result. But maybe not scalable to all fold methods. In my opinion, if the API for reshaping the attribute was rather 

```
 DenseElementsAttr::reshape(ArrayRef<int64_t> newShape)
 ```
 
 instead of 

```
 DenseElementsAttr::reshape(ShapedType newType)
 ```
 
 As outlined in https://github.com/llvm/llvm-project/pull/149947 then this issue would not have arisen in https://github.com/llvm/llvm-project/pull/147691 


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