Honor Reshape allowzero in symbolic_shape_infer#28470
Open
1fanwang wants to merge 1 commit into
Open
Conversation
The Python symbolic_shape_infer tool was treating every 0 in a Reshape shape input as "copy the corresponding input dim", which is only valid when allowzero=0. With allowzero=1 (opset 14+), a 0 in the shape tensor means a literal zero dim — used for legitimately zero-element tensors in dynamic-shape models exported from frameworks like PyTorch. Read the allowzero attribute and skip the copy-from-input path when it is set, so the explicit zero is preserved. Also guard the deferred-dim (-1) computation against a non_deferred_size of 0, which can happen when a literal 0 is combined with -1 (invalid per spec, but should not crash inference). Without this fix, e.g. Reshape(input=[4,2,0], shape=[0,0,4], allowzero=1) infers as [4,2,4] instead of [0,0,4], which then mis-shapes every downstream op when the model is processed by quantization, optimum, or any tool that consumes symbolic_shape_infer output.
Author
|
@microsoft-github-policy-service agree |
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.
symbolic_shape_infer.py::_infer_Reshapereads the shape input but ignores theallowzeroattribute introduced in opset 14. Under defaultallowzero=0, a zero inshapemeans "copy the corresponding input dim", soreshape([0, 8, 2] → [0, 0, 4])correctly resolves to[0, 8, 4]for a non-empty input but should stay[0, 0, 4]for a zero-size input. Underallowzero=1, zeros are literal regardless of input shape.Today the inferrer treats zero in
shapeas copy-from-input unconditionally. So a shape produced byreshape(allowzero=1, shape=[0, 0, 4])is reported as[N, 8, 4]instead of[0, 0, 4], propagating wrong dims through every downstream op the tool inspects. The shape is consumed by quantization preprocessing, optimum, and several converters — they all see wrong tensor shapes silently.The fix reads the
allowzeroattribute and short-circuits the copy-from-input substitution when it's1. The-1deferred-dim path is updated to handle the edge case where allowzero=1 makes the divisor zero (the reference C++ runtime errors in this case; the inferrer should too rather than silently divide-by-zero).The C++ optimizer side of the same gap is being addressed by Copilot bot's #28455; this PR is the symbolic-inference side.
Tests
Four new cases in
TestSymbolicShapeInferenceForOperators:allowzero=1literal zeros preserved (the issue's reproducer shape)allowzero=1with-1deferred-dim erroring instead of silently dividing by zeroallowzero=0legacy path unchanged (copy-from-input still works)allowzero=0with a-1and a0in the shape (combined case)Related: #28449 / #28455 cover the C++ optimizer surface of the same allowzero gap; this PR is the Python tool's surface.