[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 llvmlistbot at llvm.org
Fri Mar 7 06:15:20 PST 2025


sahas3 wrote:

> A difference with tensorflow isn't enough reason to change the TOSA implementation. Are the new semantics mandated by the TOSA spec? It [says](https://www.mlplatform.org/tosa/tosa_spec.html#_cast)
> 
> ```
> Casting from floating-point to integer:
> ...
> - Result overflows must be saturated.
> ```
> 
> and the pseudo implementation is
> 
> ```
> out = truncate<out_t>(apply_clip_s<i32_t>(round_to_nearest_int(in), minimum_s<out_t>(), maximum_s<out_t>()));
> ```
> 
> which tells me that the current behavior of casting F64 max to i64 9223372036854775807 is correct.

That's a fair point. I suppose to match numeric, the fix should be at the `tfl-to-tosa` and `torch-to-tosa` passes instead? Added @sjarus  and @GeorgeARM  to get their thoughts on this as well.

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


More information about the Mlir-commits mailing list