Add support for clamp op

[mmanzoorTT]

• Add end-to-end implementation of the ops.
• Add stablehlo to ttir conversion for clamp op.

[tapspatel]

add a clamp and clip test for perf_unit under Silicon/TTNN/perf_unit

[mmanzoorTT]

add a clamp and clip test for perf_unit under Silicon/TTNN/perf_unit

@tapspatel tests added. thanks

[tapspatel]

flatbuffer files and .mlir files look good!

[sdjordjevicTT]

Clip is just an alias for clamp op, do we want both ops in TTIR?

[mmanzoorTT]

Clip is just an alias for clamp op, do we want both ops in TTIR?

I added it to have one-to-one mapping between TTIR and TTNN. I can remove ttir.clip op.

[sdjordjevicTT]

Clip is just an alias for clamp op, do we want both ops in TTIR?

I added it to have one-to-one mapping between TTIR and TTNN. I can remove ttir.clip op.

I am not blocking, just wondering what would be the best solution. I saw that TTNN also aliases one op to another, hence maybe we should keep them both...

[sdjordjevicTT]

We agreed to keep a single op per the discussion here:
#852 (comment)

Please keep only the clamp and remove the clip op from this PR.

[mmanzoorTT]

We agreed to keep a single op per the discussion here: #852 (comment)

Please keep only the clamp and remove the clip op from this PR.

@sdjordjevicTT Do you mean to remove ttir.clip op only OR remove it entirely (ttir.clip op along with ttnn.clip and flatbuffer/runtime support)?

[sdjordjevicTT]

We agreed to keep a single op per the discussion here: #852 (comment)
Please keep only the clamp and remove the clip op from this PR.

@sdjordjevicTT Do you mean to remove ttir.clip op only OR remove it entirely (ttir.clip op along with ttnn.clip and flatbuffer/runtime support)?

We synced over the slack and agreed to remove the ttir.clip op entirely.

[mmanzoorTT]

@sdjordjevicTT clip op removed entirely.

[jnie-TT]

Runtime changes look good!

[sdjordjevicTT]

Why do we have inputs defined as variadic? Shouldn't we use a single input? Like in TTNN API:
https://github.com/tenstorrent/tt-metal/blob/a5d9979eb38ca89d7dea9ccaf5c3c684a7f6b2d8/ttnn/cpp/ttnn/operations/eltwise/unary/unary_composite.hpp#L119

[mmanzoorTT]

We are using TTNNToFlatbuffer.cpp::createEltwiseOp(...) to handle both binary and unary ops. Variadic inputs provide a way to handle all eltwise ops with same code. I can refactor the code and have separate function to handle unary ops. Then we won't need variadic inputs. I can refactor it in a separate PR. what do you suggest?

[sdjordjevicTT]

Honestly, I'm not sure, but I think we are breaking some logical structure here. If we leave it like this, we are not making an abstraction of unary op in MLIR, but we do in the runtime. We should either inherit from the unary operation table definition in MLIR or handle this operation separately in runtime, similar to how we manage the Softmax operation. What are your thoughts?

[mmanzoorTT]

I am more inclined towards refactoring createEltwiseOp into 1) createEltwiseUnaryOp and 2) createEltwiseBinaryOp (and match it with runtime abstraction). We should also convert variadic input/output definitions to non-variadic definitions for unary/binary ops which will make TTIR/TTNN dialect more precise.
My initial runtime implementation handled clamp op independently similar to Softmax op but we decided to handle clamp op as unary to match tt-metal implementation.

[jnie-TT]

@mmanzoorTT @sdjordjevicTT chiming in here about the runtime implementation. Softmax is implemented separately because it's not modelled as an eltwise op in ttnn. It's a separate normalization op in the ttnn lib, therefore we model it as an independent normalization op in our runtime. Clamp however is modelled as an eltwise unary op in ttnn lib so we should model it as a unary op in our runtime as well. This follows the general north star of our runtime reflecting the modelling of ttnn runtime as closely as possible

[sdjordjevicTT]

Thanks for the clarification folks, really appreciated it. I see, in general for unary ops, we are extending the TTNN_ElementwiseUnaryOp which further extends TTNN_ElementwiseOp and it actually has variadic inputs and outputs and is modeled as DPS.

I'm wondering if we could implement a similar structure for elementwise operations that are not DPS. Instead of simply inheriting from TTNN_Op, could we establish a hierarchy as follows:

TTNN_ClampOp -> TTNN_ElementwiseUnaryOpNonDPS -> TTNN_ElementwiseOpNonDPS -> TTNN_Op

[mmanzoorTT]

Thanks @jnie-TT for the input. I agree with you @sdjordjevicTT. I'll create an issue for this change and handle them in a separate PR. We have few other non DPS ops and I prefer to change all of them together.

[sdjordjevicTT]

Great, thanks!

[mmanzoorTT]

issue created #1270. Please have a look @sdjordjevicTT