-
Notifications
You must be signed in to change notification settings - Fork 30
[AutoBump] Merge with fixes of a58e774f (Jan 28) (1) #700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mgehre-amd
wants to merge
6
commits into
aie-public
Choose a base branch
from
bump_to_a58e774f
base: aie-public
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
23ba3f9 to
0816361
Compare
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 |
This was referenced Nov 7, 2025
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.
Collaborator
Author
Done |
jorickert
approved these changes
Nov 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adjust for LLVM bump_to_a58e774f torch-mlir#633
Adjust for llvm bump to a58e774f onnx-mlir#478
Bump LLVM to c27444ab4976dd9ff131212f87463f9945ab28d7 mlir-xten#187
[mlir][tosa] Make TOSA MUL's Shift an Input (#121953)
The TOSA-v1.0 specification makes the shift attribute of the MUL
(Hammard product) operator an input. Move the
shiftparameter of theMUL operator in the MILR TOSA dialect from an attribute to an input and
update any lit tests appropriately.
Expand the verifier of the
tosa::MulOpoperation to check the variousconstraints 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]
Also cherry-picked llvm/llvm-project@20ae283
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.