TosaToLinalg: Fix unsigned tosa.clamp

[mgehre-amd]

Lowering tosa.clamp with unsigned integer element types needs to use cmpi ult instead of cmpi slt,
and the lower/upper bound must be interpreted as unsigned when converting to to arith.constants.

[github-actions]

:white_check_mark: With the latest revision this PR passed the C/C++ code formatter.

[cferry-AMD]

We should add a failing test with ui64:

  %failure = tosa.clamp %arg1 {min_int = -1 : i64, max_int = 5 : i64, min_fp = 1.0 : f32, max_fp = 5.0 : f32} : (tensor<1xui64>) -> tensor<1xui64>

Such a test will be useful to point out there is a hardcoded 63-bit limit in this pass, to be dealt with whenever larger integer support comes in.

[cferry-AMD]

Looks good!

[TinaAMD]

LGTM

One conceptual issue with clamp in general which we could think about fixing:
The tosa spec defines that the input+output type as well as the type of the attributes (min/max) need to be the same. It would be neat to enforce this (table gen + verifier), as it would prevent people from writing clip ranges which do not make sense for the given data type (as the case tested here, with unsigned inputs and a -1 lower bound).

[mgehre-amd]

We should add a failing test with ui64:

  %failure = tosa.clamp %arg1 {min_int = -1 : i64, max_int = 5 : i64, min_fp = 1.0 : f32, max_fp = 5.0 : f32} : (tensor<1xui64>) -> tensor<1xui64>

Such a test will be useful to point out there is a hardcoded 63-bit limit in this pass, to be dealt with whenever larger integer support comes in.

Thanks! I add such test now.