[OnnxToTorch] Preserve element types in MatMulInteger when zero-points are absent#4531
Open
Abhishek-Varma wants to merge 1 commit intollvm:mainfrom
Open
[OnnxToTorch] Preserve element types in MatMulInteger when zero-points are absent#4531Abhishek-Varma wants to merge 1 commit intollvm:mainfrom
Abhishek-Varma wants to merge 1 commit intollvm:mainfrom
Conversation
…s are absent The MatMulInteger lowering unconditionally widened i8/u8 operands to i32 before creating aten.matmul, even when no zero-point operands were provided (symmetric quantization, zp=0). This destroyed the narrow element type information early in the pipeline, preventing downstream passes from selecting appropriate hardware intrinsics (e.g. i8 MAC instructions) that depend on seeing the original element types. When both zero-point operands are absent, skip the i32 widening and zero-point subtraction entirely and emit aten.matmul with the original i8/u8 operands. The existing i32 path is preserved when at least one zero-point is provided, since subtracting a non-zero zero-point from an i8 value requires a wider type to avoid overflow. Signed-off-by: Abhishek Varma <abhvarma@amd.com>
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
1 participant
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 MatMulInteger lowering unconditionally widens operands to i32 before creating aten.matmul, even when no zero-point operands were provided (symmetric quantization, zp=0). This destroyed the narrow element type information early in the pipeline, preventing downstream passes from selecting appropriate hardware intrinsics (e.g. i8 MAC instructions) that depend on seeing the original element types.
When both zero-point operands are absent, skip the i32 widening and zero-point subtraction entirely and emit aten.matmul with the original (i8/u8) operands. The existing i32 path is preserved when at least one zero-point is provided, since subtracting a non-zero zero-point from an i8 (or any low bit-width) value requires a wider type to avoid overflow.
Signed-off-by: Abhishek Varma abhvarma@amd.com