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

[Georgios Pinitas]

GeorgeARM wrote:

Is rather strange reasoning about correctness on the boundaries of undefined behavior.
Truth be told think the explicit behavior that TOSA has is the "safest" one and easiest to deploy against validation flows. Having different behaviours will mean that the legalization in order to produce "correct" results they will need to be tuned (unless I am missing something) for the specific backend which really beats the purpose of TOSA.
Echoing @eric-k256 question, are there real use-cases that requires this wrap-around behaviour or is it that synthetic validation tests fail?

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