[Mlir-commits] [mlir] [mlir][tosa][tosa-to-linalg] tosa.cast: fix answer mismatch to cast f64/f32 max value to i64/i32 (PR #130116)

[Sayan Saha]

sahas3 wrote:

Re-reading the [TOSA spec](https://www.mlplatform.org/tosa/tosa_spec.html#_overview) I see:
> The intent is to enable a variety of implementations running on a diverse range of processors, with the results at the TOSA level consistent across those implementations. ....  Most operators from the common ML frameworks (TensorFlow, PyTorch, etc.) should be expressible in TOSA. It is expected that there will be tools to lower from ML frameworks into TOSA."

So it seems matching the behavior of ML frameworks like TF/PyTorch exactly was never the goal for TOSA spec. It only serves as an intermediary IR to be able to target various HW backends from the ML frameworks. Interestingly the behavior of TOSA is inline with what happens in JAX:

```
>>>import jax.numpy as jnp
>>> max_float32 = jnp.finfo(jnp.float32).max
>>> print(max_float32)
3.4028235e+38
>>> jnp.astype(max_float32, jnp.int32)
Array(2147483647, dtype=int32)
```

While I understand that having an option to match TOSA spec to that of the different ML frameworks will be nice to have such that there is a single implementation that does the right thing when lowering from TF/PyTorch to TOSA and subsequently to Linalg, it's hard to argue why that onus should be on TOSA spec instead of the individual `xxx-to-tosa` passes.

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