[mlir] Redundant signed cast attribute added when building `linalg.matmul`

[andfau-amd]

The Python bindings for constructing linalg.matmul, linalg.matmul_transpose_a and linalg.matmul_transpose_b add redundant cast attributes. For example:

%2 = linalg.matmul_transpose_b {cast = #linalg.type_fn<cast_signed>} ins(%arg0, %arg1 : tensor<512x14336xf16>, tensor<4096x14336xf16>) outs(%1 : tensor<512x4096xf32>) -> tensor<512x4096xf32>

Here the {cast = #linalg.type_fn<cast_signed>} is meaningless because the result type is float. Moreover, at least when using the Python builder functions (linalg.matmul(), linalg.matmul_transpose_a(), linalg.matmul_transpose_b()), it is not possible to request that this attribute not be added.

There are a few ways to look at this issue:

• Is the problem that this builder is adding the attribute unconditionally?
• Is the problem that the assembly format is showing the attribute even when it has the default value?

I am not sure if this should be seen as purely a Python bindings issue or if it has C++ ramifications.

Please see this discussion for more context: https://github.com/nod-ai/iree-kernel-benchmark/pull/57/files#r2006203540

[llvmbot]

@llvm/issue-subscribers-mlir

Author: Andrea Faulds (andfau-amd)

The Python bindings for constructing `linalg.matmul`, `linalg.matmul_transpose_a` and `linalg.matmul_transpose_b` add redundant `cast` attributes. For example:

%2 = linalg.matmul_transpose_b {cast = #linalg.type_fn<cast_signed>} ins(%arg0, %arg1 : tensor<512x14336xf16>, tensor<4096x14336xf16>) outs(%1 : tensor<512x4096xf32>) -> tensor<512x4096xf32>

Here the {cast = #linalg.type_fn<cast_signed>} is meaningless because the result type is float. Moreover, at least when using the Python builder functions (linalg.matmul(), linalg.matmul_transpose_a(), linalg.matmul_transpose_b()), it is not possible to request that this attribute not be added.

There are a few ways to look at this issue:

• Is the problem that this builder is adding the attribute unconditionally?
• Is the problem that the assembly format is showing the attribute even when it has the default value?

I am not sure if this should be seen as purely a Python bindings issue or if it has C++ ramifications.

Please see this discussion for more context: https://github.com/nod-ai/iree-kernel-benchmark/pull/57/files#r2006203540

[llvmbot]

@llvm/issue-subscribers-mlir-python

Author: Andrea Faulds (andfau-amd)

The Python bindings for constructing `linalg.matmul`, `linalg.matmul_transpose_a` and `linalg.matmul_transpose_b` add redundant `cast` attributes. For example:

%2 = linalg.matmul_transpose_b {cast = #linalg.type_fn<cast_signed>} ins(%arg0, %arg1 : tensor<512x14336xf16>, tensor<4096x14336xf16>) outs(%1 : tensor<512x4096xf32>) -> tensor<512x4096xf32>

Here the {cast = #linalg.type_fn<cast_signed>} is meaningless because the result type is float. Moreover, at least when using the Python builder functions (linalg.matmul(), linalg.matmul_transpose_a(), linalg.matmul_transpose_b()), it is not possible to request that this attribute not be added.

There are a few ways to look at this issue:

• Is the problem that this builder is adding the attribute unconditionally?
• Is the problem that the assembly format is showing the attribute even when it has the default value?

I am not sure if this should be seen as purely a Python bindings issue or if it has C++ ramifications.

Please see this discussion for more context: https://github.com/nod-ai/iree-kernel-benchmark/pull/57/files#r2006203540

[llvmbot]

@llvm/issue-subscribers-mlir-linalg

Author: Andrea Faulds (andfau-amd)

The Python bindings for constructing `linalg.matmul`, `linalg.matmul_transpose_a` and `linalg.matmul_transpose_b` add redundant `cast` attributes. For example:

%2 = linalg.matmul_transpose_b {cast = #linalg.type_fn<cast_signed>} ins(%arg0, %arg1 : tensor<512x14336xf16>, tensor<4096x14336xf16>) outs(%1 : tensor<512x4096xf32>) -> tensor<512x4096xf32>

Here the {cast = #linalg.type_fn<cast_signed>} is meaningless because the result type is float. Moreover, at least when using the Python builder functions (linalg.matmul(), linalg.matmul_transpose_a(), linalg.matmul_transpose_b()), it is not possible to request that this attribute not be added.

There are a few ways to look at this issue:

• Is the problem that this builder is adding the attribute unconditionally?
• Is the problem that the assembly format is showing the attribute even when it has the default value?

I am not sure if this should be seen as purely a Python bindings issue or if it has C++ ramifications.

Please see this discussion for more context: https://github.com/nod-ai/iree-kernel-benchmark/pull/57/files#r2006203540

[rengolin]

@makslevental, @nicolasvasilache, @ftynse: this sounds like a Python API issue.

@andfau-amd, have you thought of using the new matmul with transpose affine maps instead of matmul_transpose_b? The python builder already works with it.

https://mlir.llvm.org/docs/Dialects/Linalg/#linalgmatmul-linalgmatmulop

[makslevental]

This was a change introduced in or around this PR #126377 (i.e., possibly in the prior PR that broke things and then the subsequent PR fixed) - prior matmul did not behave in this way. I have not investigated because I am not up to speed on what you guys are doing with linalg OpDSL deprecation.

[rengolin]

@shahidact @rolfmorel, any ideas?