Repository navigation
[xmc] Keep constant payload type in PushTransposeThroughBinaryWithConst - #1083
Merged
sambanerxilinxamd merged 3 commits intoOct 21, 2026
Conversation
rachgupt93
suggested changes
Oct 19, 2026
|
Better can we just add transpose into constant and let constant folding take care instead of we doing it while moving tranpose down |
nvunnam57128
force-pushed
the
nvunnam.fix-transpose-binary-const-float-payload
branch
from
October 20, 2026 06:58
be29ce4 to
ca3b4bb
Compare
rachgupt93
approved these changes
Oct 21, 2026
The pattern rebuilt the transposed constant using the storage type of the
constant's result type. When the payload has a different element type
(e.g. f32 data behind a !quant.uniform<i8:f32> result), the splat path
asserted in DenseElementsAttr::get ("expected float attribute type to equal
element type") and the non-splat path reinterpreted the f32 bytes as i8,
silently producing wrong values.
Rebuild the payload in its own element type and iterate it as
mlir::Attribute; the result type (including per-axis quant remapping) is
unchanged.
Allow non-splat f16 constants through the payload-type check and add a lit test that checks the transposed f16 values.
…BinaryWithConst Instead of transposing the constant's data in the pattern, feed the binary op Transpose(const, invPerm) and let ConstPropONNXToONNXPass, which runs right after this pass in the XMC pipeline, fold it. Folding uses OnnxElementsAttrBuilder::transpose, which works on the payload's own element type, so the per-type handling is no longer needed. Value tests move to onnx_transpose_optimization_const_fold.mlir, which runs both passes; the pass-only test checks the inserted Transpose.
nvunnam57128
force-pushed
the
nvunnam.fix-transpose-binary-const-float-payload
branch
from
October 21, 2026 08:13
ca3b4bb to
e96ff21
Compare
sambanerxilinxamd
approved these changes
Oct 21, 2026
sambanerxilinxamd
merged commit Oct 21, 2026
2e4f873
into
Xilinx:feature/onnx-to-tosa
3 checks passed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
The pattern rebuilt the transposed constant using the storage type of the constant's result type. When the payload has a different element type (e.g. f32 data behind a !quant.uniformi8:f32 result), the splat path asserted in DenseElementsAttr::get ("expected float attribute type to equal element type") and the non-splat path reinterpreted the f32 bytes as i8, silently producing wrong values.
Rebuild the payload in its own element type and iterate it as mlir::Attribute; the result type (including per-axis quant remapping) is unchanged.