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

[llvmlistbot at llvm.org]

ivangarcia44 wrote:





> You're comparing against a single backend of TensorFlow and PyTorch in these cases, I don't see a guarantee that other backends would have the same behavior, which would make the change suggested here mismatch those implementations.
> 
> Relying on undefined behavior in your testing seems dangerous, and is what appears to be happening here. Is there a practical use for changing the TOSA behavior that would be helpful for real world use cases?

Since PyTorch/Tensorflow don't saturate on overflow, then all hardware backends should do the same for numerical equivalence.

Even if this is not the case, having an attribute on the TOSA cast operation to control the saturation behavior should not hurt. If the default value of this attribute is to saturate, then nothing should be broken. It is up to the user to decide what works best for their infrastructure.

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