Repository navigation
Keep the shape operand of view_as and expand_as out of shared qparams (#24153) - #24153
Merged
Merged
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24153
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit 85c948a with merge base 893d815 ( BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
meta-cla
Bot
added
the
CLA Signed
Contributor
|
@pssrawat has exported this pull request. If you are a Meta employee, you can view the originating Diff in D127380012. |
meta-codesync
Bot
changed the title
expand_as through the existing shared-qparams expand pathexpand_as through the existing shared-qparams expand path (#24153)
pssrawat
force-pushed
the
export-D127380012
branch
from
October 28, 2026 21:28
4b45f5f to
f5c6eea
Compare
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 28, 2026
pytorch#24153) Summary: `SharedQspecQuantizer` already gives `expand` and `expand_copy` shared qparams when a neighbor is quantized, and the lowering then runs `expand_copy` on int8. `expand_as` is not in that list, and it only decomposes to `expand` at `to_edge`, after quantization, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. `ExpandAsToExpandPass` runs in `transform_for_annotation` and rewrites `expand_as(x, other)` into `expand(x, other.shape)`, emitting `sym_size` nodes for symbolic dims. `expand_as` then gets the same neighbor-driven treatment as `expand`: int8 when its neighbors are quantized, float otherwise. The shape-only `other` operand is no longer an input of the op, so it is never pulled into the shared-qparams cluster. No new pattern check or support-dict entry is added for `expand`, so an expand between float-only ops is not forced to int8. Differential Revision: D127380012
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 29, 2026
pytorch#24153) Summary: `SharedQspecQuantizer` already gives `expand` and `expand_copy` shared qparams when a neighbor is quantized, and the lowering then runs `expand_copy` on int8. `expand_as` is not in that list, and it only decomposes to `expand` at `to_edge`, after quantization, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. `ExpandAsToExpandPass` runs in `transform_for_annotation` and rewrites `expand_as(x, other)` into `expand(x, other.shape)`, emitting `sym_size` nodes for symbolic dims. `expand_as` then gets the same neighbor-driven treatment as `expand`: int8 when its neighbors are quantized, float otherwise. The shape-only `other` operand is no longer an input of the op, so it is never pulled into the shared-qparams cluster. No new pattern check or support-dict entry is added for `expand`, so an expand between float-only ops is not forced to int8. Differential Revision: D127380012
pssrawat
force-pushed
the
export-D127380012
branch
from
October 29, 2026 06:25
f5c6eea to
55155eb
Compare
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 29, 2026
pytorch#24153) Summary: `SharedQspecQuantizer` already gives `expand` and `expand_copy` shared qparams when a neighbor is quantized, and the lowering then runs `expand_copy` on int8. `expand_as` is not in that list, and it only decomposes to `expand` at `to_edge`, after quantization, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. `ExpandAsToExpandPass` runs in `transform_for_annotation` and rewrites `expand_as(x, other)` into `expand(x, other.shape)`, emitting `sym_size` nodes for symbolic dims. `expand_as` then gets the same neighbor-driven treatment as `expand`: int8 when its neighbors are quantized, float otherwise. The shape-only `other` operand is no longer an input of the op, so it is never pulled into the shared-qparams cluster. No new pattern check or support-dict entry is added for `expand`, so an expand between float-only ops is not forced to int8. Differential Revision: D127380012
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 29, 2026
pytorch#24153) Summary: `SharedQspecQuantizer` already gives `expand` and `expand_copy` shared qparams when a neighbor is quantized, and the lowering then runs `expand_copy` on int8. `expand_as` is not in that list, and it only decomposes to `expand` at `to_edge`, after quantization, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. `ExpandAsToExpandPass` runs in `transform_for_annotation` and rewrites `expand_as(x, other)` into `expand(x, other.shape)`, emitting `sym_size` nodes for symbolic dims. `expand_as` then gets the same neighbor-driven treatment as `expand`: int8 when its neighbors are quantized, float otherwise. The shape-only `other` operand is no longer an input of the op, so it is never pulled into the shared-qparams cluster. No new pattern check or support-dict entry is added for `expand`, so an expand between float-only ops is not forced to int8. Differential Revision: D127380012
pssrawat
force-pushed
the
export-D127380012
branch
from
October 29, 2026 20:26
55155eb to
76c0392
Compare
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 29, 2026
pytorch#24153) Summary: `SharedQspecQuantizer` already gives `expand` and `expand_copy` shared qparams when a neighbor is quantized, and the lowering then runs `expand_copy` on int8. `expand_as` is not in that list, and it only decomposes to `expand` at `to_edge`, after quantization, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. `ExpandAsToExpandPass` runs in `transform_for_annotation` and rewrites `expand_as(x, other)` into `expand(x, other.shape)`, emitting `sym_size` nodes for symbolic dims. `expand_as` then gets the same neighbor-driven treatment as `expand`: int8 when its neighbors are quantized, float otherwise. The shape-only `other` operand is no longer an input of the op, so it is never pulled into the shared-qparams cluster. No new pattern check or support-dict entry is added for `expand`, so an expand between float-only ops is not forced to int8. Differential Revision: D127380012
meta-codesync
Bot
changed the title
expand_as through the existing shared-qparams expand path (#24153)
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 30, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Differential Revision: D127380012
pssrawat
force-pushed
the
export-D127380012
branch
from
October 30, 2026 05:48
76c0392 to
eb2f222
Compare
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 30, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Differential Revision: D127380012
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 30, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Differential Revision: D127380012
pssrawat
force-pushed
the
export-D127380012
branch
from
October 30, 2026 07:25
eb2f222 to
c8655ab
Compare
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Oct 30, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Differential Revision: D127380012
rascani
approved these changes
Nov 2, 2026
rascani
left a comment
rascani
left a comment
Contributor
There was a problem hiding this comment.
Review automatically exported from Phabricator review in Meta.
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Nov 2, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Reviewed By: rascani Differential Revision: D127380012
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Nov 2, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Reviewed By: rascani Differential Revision: D127380012
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Reviewed By: rascani Differential Revision: D127380012
pssrawat
force-pushed
the
export-D127380012
branch
from
November 2, 2026 22:09
a4381a0 to
85c948a
Compare
pssrawat
added a commit
to pssrawat/executorch
that referenced
this pull request
Nov 2, 2026
…pytorch#24153) Summary: `SharedQspecQuantizer` gives each shared-qparams cluster one set of qparams for every float input and output of its ops. `view_as(x, other)` is in that list, and the cluster was built from all of its inputs, so `other` was pulled in even though it contributes only its shape. `x` and `other` were then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped. For example, in `(x * y).view_as(other) + other` with `other = z + z`, `x * y` spans about ±2.5 and `other` about ±51. `x * y` was quantized at `other`'s scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is written `reshape(4, 8)`, and the output error against float rose from 0.258 to 0.307. `expand_as` has the same shape-only second operand but was not in the shared-qparams list at all, so every `expand_as` broadcast stayed in float behind a dequantize and a requantize. Shape-as ops (`view_as`, `expand_as`) now share qparams only through their data operand, `args[0]`. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer. `expand_as` joins the shared-qparams ops, so like `expand` it is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8 `expand_copy`. Authored with Claude Code. Reviewed By: rascani Differential Revision: D127380012
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
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.
Summary:
SharedQspecQuantizergives each shared-qparams cluster one set of qparams for every float input and output of its ops.view_as(x, other)is in that list, and the cluster was built from all of its inputs, sootherwas pulled in even though it contributes only its shape.xandotherwere then quantized with one scale, set by whichever has the wider range: the data loses precision, or the shape operand is clipped.For example, in
(x * y).view_as(other) + otherwithother = z + z,x * yspans about ±2.5 andotherabout ±51.x * ywas quantized atother's scale of 0.349, about 18x coarser than the 0.0195 it gets when the same reshape is writtenreshape(4, 8), and the output error against float rose from 0.258 to 0.307.expand_ashas the same shape-only second operand but was not in the shared-qparams list at all, so everyexpand_asbroadcast stayed in float behind a dequantize and a requantize.Shape-as ops (
view_as,expand_as) now share qparams only through their data operand,args[0]. The cluster walk does not cross the edge to the shape operand in either direction, and that operand gets no shared input qspec, so it keeps the qparams of its own producer.expand_asjoins the shared-qparams ops, so likeexpandit is quantized to int8 when its neighbours are, and lowers on Cortex-M to an int8expand_copy.Authored with Claude Code.
Reviewed By: rascani
Differential Revision: D127380012