[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