This is an archive of the discontinued LLVM Phabricator instance.

[mlir][tosa] Add type checking traits to the appropriate ops
ClosedPublic

Authored by tatwaichong on May 12 2023, 11:54 AM.

Details

Summary

Add the trait SameOperandsAndResultElementType and
SameOperandsElementType to verify ops that are known
to have the same input and output type rather than generate
an invalid tosa IR with mixed data types like:

"tosa.add"(%0, %1) : (tensor<nxbf16>, tensor<nxf32>) -> tensor<nxf32>

Thus apply tosa.cast prior if needed.

Change-Id: Ie866b84e371e3b571ec04f7abb090c216dd39c33

Diff Detail

Event Timeline

tatwaichong created this revision.May 12 2023, 11:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2023, 11:54 AM
tatwaichong requested review of this revision.May 12 2023, 11:54 AM
jpienaar accepted this revision.May 14 2023, 11:08 AM
This revision is now accepted and ready to land.May 14 2023, 11:08 AM

Thanks for fixing this!

I think clamp, sigmoid and tanh are also Tosa_ElemWiseUnaryOp.
Other ops like identity, reshape, concat, pad, reverse, slice, tile and transpose should also have same element types on input and output.

Declaring clamp, sigmoid and tanh as Tosa_ElemWiseUnaryOp.

Thanks for fixing this!

I think clamp, sigmoid and tanh are also Tosa_ElemWiseUnaryOp.
Other ops like identity, reshape, concat, pad, reverse, slice, tile and transpose should also have same element types on input and output.

Good spot! Yes, these activation functions are element-wise operations essentially. Add them into the group as suggested.
For other non element-wise operations ops like pad, transpose, etc, there is a representation difference between tosa definition in mlir dialect and tosa spec, e.g. padding is operand type in mlir, whereas it is an attribute type in tosa spec. That way we have more chance let tosa operation to support dynamic shape. However, as a result, mlir built-in type checking trait treat those arguments as operand but not attribute so end up happening element types mismatch as the attribute type can differ from the input tensor's.

Can we cover element-wise op in this PR for now? Let's think about how to implement the checking for other in a sperate patch?

Thanks for fixing this!

I think clamp, sigmoid and tanh are also Tosa_ElemWiseUnaryOp.
Other ops like identity, reshape, concat, pad, reverse, slice, tile and transpose should also have same element types on input and output.

Good spot! Yes, these activation functions are element-wise operations essentially. Add them into the group as suggested.
For other non element-wise operations ops like pad, transpose, etc, there is a representation difference between tosa definition in mlir dialect and tosa spec, e.g. padding is operand type in mlir, whereas it is an attribute type in tosa spec. That way we have more chance let tosa operation to support dynamic shape. However, as a result, mlir built-in type checking trait treat those arguments as operand but not attribute so end up happening element types mismatch as the attribute type can differ from the input tensor's.

Can we cover element-wise op in this PR for now? Let's think about how to implement the checking for other in a sperate patch?

Sounds good!

Fix the typo of Binary to Unary for clamp, sigmoid and tanh.

put tosa.mul into element-wise binary group.

With this PR, "tosa.mul"(%0, %1) {shift = 0 : i32} : (tensor<4xi8>, tensor<4xi8>) -> tensor<4xi32> is marked as illegal because result and operand types don't match, even though i8xi8 = i32 is according to the spec: https://www.mlplatform.org/tosa/tosa_spec.html#_mul

@mgehre-amd, oh, you're right. I'll send a PR to fix this soon.