[Mlir-commits] [mlir] [mlir][linalg] Add 'compute_element_type' to linalg.elementwise op. (PR #190566)

Javed Absar llvmlistbot at llvm.org
Mon Apr 6 12:35:10 PDT 2026


================
@@ -163,3 +163,28 @@ func.func @ternary(%A : tensor<32x16xi1>, %B: tensor<8x16x32xf32>, %C : tensor<8
       outs(%D: tensor<8x16x32xf32>) -> tensor<8x16x32xf32>
   return %r : tensor<8x16x32xf32>
 }
+// -----
+// CHECK-DAG: #[[IDENTITY:.+]] = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
+//
+// CHECK: @unary_upcast_exp(%[[A:.+]]: tensor<8x16x32xf16>, %[[B:.+]]: tensor<8x16x32xf32>)
+// CHECK: linalg.generic
+// CHECK-SAME: indexing_maps = [#[[IDENTITY]], #[[IDENTITY]]]
+// CHECK-SAME: iterator_types = ["parallel", "parallel", "parallel"]
+//
+// CHECK-SAME: ins(%[[A]]
+// CHECK-SAME: outs(%[[B]]
+//
+// CHECK: ^{{.*}}(%[[IN:.+]]: f16, %[[OUT:.+]]: f32)
+// CHECK:   %[[EXT:.+]] = arith.extf %[[IN]] : f16 to f32
+// CHECK:   %[[EXP:.+]] = math.exp %[[EXT]] : f32
+// CHECK:   linalg.yield %[[EXP]] : f32
+//
+func.func @unary_upcast_exp(%A : tensor<8x16x32xf16>, %B : tensor<8x16x32xf32>) -> tensor<8x16x32xf32> {
+  %r = linalg.elementwise
+      kind = #linalg.elementwise_kind<exp>
+      compute_element_type = f32
----------------
javedabsar1 wrote:

OK currently (without this PR), if input is f16 and output if f32, it will result in error i.e.
```
$ cat t.mlir
func.func @unary_identity_exp(%A : tensor<8x16x32xf16>, %B: tensor<8x16x32xf32>) ->  tensor<8x16x32xf32> {
  %r = linalg.elementwise
      kind=#linalg.elementwise_kind<exp>
      ins(%A : tensor<8x16x32xf16>)
      outs(%B: tensor<8x16x32xf32>) -> tensor<8x16x32xf32>
  return %r : tensor<8x16x32xf32>
}
$ mlir-opt t.mlir
 ...
 error: 'linalg.yield' op type of yield operand 1 ('f16') doesn't match the element type of the enclosing linalg.generic op ('f32')
 ```
 Now, do you want this PR to address just this i.e. the above `linalg.elementwise` example becomes valid, AND therefore the when it is lowered to  `linalg.generic` the body of the linalg.generic will do the extf.
 
 ---
 
 Next is the question why a broader `compute_element_type` is needed. It is for scenarios where input e.g. linalg.exp is f16, but the exponentiation needs to be done on higher precision f32, and the result written out in lower precision f16.  
  
 

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


More information about the Mlir-commits mailing list