Skip to content

Conversation

@mgehre-amd
Copy link
Collaborator

@mgehre-amd mgehre-amd commented Nov 7, 2025

Also cherry-picked llvm/llvm-project@20ae283

  • Solve merge conflicts and fixed tests after bump
    Handle the upstream switch of tosa.mul to use an optional shift operand by allowing the constant folding path to accept and validate a constant zero shift tensor. Relax the shared binary folding helper to work with ops that gain extra operands so mul no longer asserts. Update the TOSA constant-folding test cases to spell out zero-shift operands, capture the new value numbering, and document these findings for future bump runs.

FranklandJack and others added 2 commits January 28, 2025 16:25
The TOSA-v1.0 specification makes the shift attribute of the MUL
(Hammard product) operator an input. Move the `shift` parameter of the
MUL operator in the MILR TOSA dialect from an attribute to an input and
update any lit tests appropriately.

Expand the verifier of the `tosa::MulOp` operation to check the various
constraints defined in the TOSA-v1.0 specification. Specifically, ensure
that all input operands (excluding the optional shift) are of the same
rank. This means that broadcasting tests which previously checked rank-0
tensors would be broadcast are no longer valid and are removed.

Signed-off-by: Jack Frankland <[email protected]>
Co-authored-by: TatWai Chong <[email protected]>
Handle the upstream switch of tosa.mul to use an optional shift operand by allowing the constant folding path to accept and validate a constant zero shift tensor. Relax the shared binary folding helper to work with ops that gain extra operands so mul no longer asserts. Update the TOSA constant-folding test cases to spell out zero-shift operands, capture the new value numbering, and document these findings for future bump runs.
@jorickert
Copy link
Contributor

I think we should cherry-pick llvm/llvm-project@20ae283 in the same bump, otherwise we need to deal two times with changes to the mul shift

Tai78641 and others added 3 commits November 11, 2025 11:50
This patch fixes merge issues in TosaOpBase.td and TosaOps.td wrt traits
on tosa elementwise ops and multiply op which, with the optional shift
operand, is no longer strictly an elementwise op.

fixed up inferReturnTypeComponents to be based on only the first two
operands (ie, ignoring shift, if present)

also fixed up TosaReduceTransposes to special handle tosa mul op now
that it is not an elementwise op.

Signed-off-by: Tai Ly <[email protected]>
Change the shift operand for the mul operator to be a required operand.

Also defined shift to be Tosa_ScalarInt8Tensor which requires that it is
a rank-1 tensor
whose shape is [1] (ie, tensor containing a single element)

Signed-off-by: Tai Ly <[email protected]>
Propagate the new TOSA mul shift operand into downstream test expectations and update onnx-mlir and torch-mlir to always supply the shift constant.
@mgehre-amd
Copy link
Collaborator Author

I think we should cherry-pick llvm/llvm-project@20ae283 in the same bump, otherwise we need to deal two times with changes to the mul shift

Done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants