[Mlir-commits] [mlir] [mlir] [arith] Fold trunc(extremum(ext(lhs), ext(rhs))) (PR #214658)

[Mehdi Amini]

joker-eph wrote:

Maybe what you're saying is that the semantics of `trunc(matmul(bf16, bf16) -> f32) -> bf16` isn't equivalent to `matmul(bf16, bf16) -> bf16` because the former has internal accumulation in fp32?

If so that's a much larger problem of "semantics mismatch" and not "information loss in the rewrite" IMO.

Having the return type implying the accumulation may be an OK design for the matmul op (is it clearly documented like this?), but then:

- the fold here is just plainly incorrect.
- a backend can't just decide to do `trunc(matmul(bf16, bf16) -> f32) -> bf16` when the input program is `matmul(bf16, bf16) -> bf16` (without fast-math). The numeric won't match...

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