Delegate even-kernel 'same'-padding convs via a quantized static pad (#20553) by JakeStevens · Pull Request #20553 · pytorch/executorch

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens · 2026-06-26T19:22:41Z

Summary:

When using padding="same" for a conv with even kernels, torch.export creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in xnn_status_unsupported_parameter.

This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (ConvConfig._get_act_deps) so both delegate together: for fp32 the pad lowers directly as an XNNStaticConstantPad. For quantized graphs the pad is created by to_edge decomposition after the quantizer runs, so it arrives as dq -> pad -> conv with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). InsertPadQDQPass inserts an implicit quantize -> dequantize after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation.

Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead.

Differential Revision: D109871964

pytorch-bot · 2026-06-26T19:22:45Z

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/20553

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending, 2 Unrelated Failures

As of commit 0e81ab4 with merge base 3801496 ():

NEW FAILURE - The following job has failed:

Lint / lintrunner-mypy (gh)
>>> Lint for backends/cortex_m/quantizer/pattern_matcher.py:

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

pull / android / build-android (gh) (trunk failure)
ImportError: /opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/executorch/extension/training/pybindings/_training_lib.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c104impl3cow23materialize_cow_storageERNS_11StorageImplE
pull / unittest-nxp-neutron / linux-job (gh) (trunk failure)
##[error]The operation was canceled.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

meta-codesync · 2026-06-26T19:22:50Z

@JakeStevens has exported this pull request. If you are a Meta employee, you can view the originating Diff in D109871964.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

digantdesai · 2026-07-07T16:22:17Z

+
+ An even-kernel 'same'-padding conv decomposes (after quantization) into
+ dequant -> constant_pad_nd -> convolution. Because the pad is introduced by
+ to_edge decomposition -- after the quantizer has run -- it is never annotated,


can we fuse it inside the preprocess for xnnpack or we have to run pad + conv in the XNNPACK graph? I am asking because if we can fuse it we might as well write that pass instead.

We can fuse, I have some work in that direction, was going to publish as a quick follow up since there is an external contributor with the 1d work and the change is slightly larger so preferred to do it once these both land.

…ytorch#20553) Summary: When using padding="same" for a conv with even kernels, `torch.export` creates an explicit pad node, leading to a dq -> pad -> conv chain, which is not recognized, so conv ends up undelegated. The ReLU ends up in its own partition with a quantize. XNNPACK does not support this, resulting in `xnn_status_unsupported_parameter`. This PR fixes this, allowing for full delegation to XNNPACK in this case, by pulling the zero-valued spatial pad into the conv's partition (`ConvConfig._get_act_deps`) so both delegate together: for fp32 the pad lowers directly as an `XNNStaticConstantPad`. For quantized graphs the pad is created by `to_edge` decomposition after the quantizer runs, so it arrives as `dq -> pad -> conv` with no quantize on its output and would serialize as fp32 (the conv would then reject its unquantized activation). `InsertPadQDQPass` inserts an implicit `quantize -> dequantize` after the pad, reusing the feeding dequant's params (a zero pad preserves quantization), so it lowers as a quantized static pad and the conv sees a proper dequantized activation. Note: This results in full delegation, an improvement over the existing runtime error (or portable fallback as naive fix), but the pad is executed as a separate op and results in overhead. Differential Revision: D109871964

approach) Instead of folding constant_pad_nd into asymmetric Conv2d padding, keep it as an explicit XNNPACK pad op: - Remove pad-folding logic from Conv1dUnsqueezePass - Remove Conv1dFoldedPadMetaPass (no longer needed) - Revert xnnpack_input_padding handling in op_conv2d.py - Add InsertPadQDQPass: inserts QDQ after pad in quantized contexts so it serializes as a quantized static pad This matches the approach from pytorch#20553 and fixes the crash with conv1d -> flatten (even kernel + same padding).

@GregoryComer

Fixes#20558. Related to #20553. ## Summary Quantized `nn.Conv1d(..., padding="same")` with an even kernel exports with asymmetric padding (unequal left/right amounts), which cannot be folded into the convolution's symmetric padding field. The original pad-folding approach in this PR was replaced with the explicit-PAD approach from #20553: - **InsertPadQDQPass** — inserts implicit quantize/dequantize pairs after constant_pad_nd nodes in quantized contexts so they serialize as quantized static pads. Refactored with additional guard checks (pad_value, pad_amounts, negative amounts) and correct idempotency. - **ConvolutionConfig._get_act_deps** — pulls zero-valued constant_pad_nd nodes (and their QDQ chain if InsertPadQDQPass already ran) into the convolution's partition for both 1D and 2D convs. The merged method replaces separate 1D and 2D implementations that existed on this branch. - **Regression test** — quantized Conv1d even-kernel same-padding covering both symmetric and asymmetric pad cases, validated by numerical comparison. - Removed unrelated __init__.py re-ordering and no-op conv1d_unsqueeze_pass changes. With these changes, an even-kernel `padding="same"` conv1d graph: ``` dequant -> constant_pad_nd -> convolution ``` becomes (after XNNPACK preprocessing and partitioning): ``` [dequant -> pad -> q -> dq -> conv] (single XNNPACK delegate) ``` ## Test plan ``` python -m pytest backends/xnnpack/test/ops/test_conv1d.py -q # 7 passed (1 new regression test with 4 subTests) python -m pytest backends/xnnpack/test/ops/test_conv2d.py -q # 32 passed python -m pytest backends/xnnpack/test/passes/test_insert_pad_qdq.py -q # 3 passed python -m pytest backends/xnnpack/test/ops/test_static_constant_pad.py -q # 8 passed lintrunner -a # No lint issues ``` cc @GregoryComer @digantdesai @cbilgin @JakeStevens @freddan80 @per @zingo @oscarandersson8218 @mansnils @Sebastian-Larsson @robell @rascani --------- Co-authored-by: Jacob Stevens <stevens.jacob1492@gmail.com>

JakeStevens requested a review from digantdesai as a code owner June 26, 2026 19:22

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jun 26, 2026

meta-codesyncBot added the meta-exported label Jun 26, 2026

meta-codesyncBottemporarily deployed to cadence June 26, 2026 19:22 Inactive

JakeStevens mentioned this pull request Jun 27, 2026
Conv2d with padding 'same' fails (when quantised) at runtime on XNNPACK #20517
Closed

This was referenced Jul 5, 2026
Fix quantized Conv1d same padding with even kernels in XNNPACK #20734
Merged
Quantized Conv1d with even kernel + padding="same" produces incorrect XNNPACK output #20558
Closed

meta-codesyncBot changed the title ~~Fold constant_pad_nd into convolution input padding~~Delegate even-kernel 'same'-padding convs via a quantized static pad (#20553)Jul 6, 2026

JakeStevens force-pushed the export-D109871964 branch from a04093b to 3c5db00Compare July 6, 2026 17:57

JakeStevens added the release notes: xnnpack Changes to the XNNPack backend delegate label Jul 6, 2026

JakeStevens temporarily deployed to cadence July 6, 2026 18:06 — with GitHub Actions Inactive

JakeStevens requested a review from GregoryComer July 6, 2026 18:06

JakeStevens temporarily deployed to cadence July 6, 2026 18:32 — with GitHub Actions Inactive

JakeStevens force-pushed the export-D109871964 branch from 3c5db00 to f94078bCompare July 6, 2026 18:48

JakeStevens force-pushed the export-D109871964 branch from f94078b to e46184bCompare July 7, 2026 13:24

JakeStevens force-pushed the export-D109871964 branch from e46184b to 0d1649dCompare July 7, 2026 13:30

digantdesai reviewed Jul 7, 2026
View reviewed changes

JakeStevens linked an issue Jul 7, 2026 that may be closed by this pull request
Conv2d with padding 'same' fails (when quantised) at runtime on XNNPACK #20517
Closed

GregoryComer approved these changes Jul 8, 2026
View reviewed changes

JakeStevens force-pushed the export-D109871964 branch from 0d1649d to 0e81ab4Compare July 8, 2026 17:07

meta-codesyncBot merged commit 420a8ab into pytorch:mainJul 8, 2026
181 of 184 checks passed

JakeStevens deleted the export-D109871964 branch July 9, 2026 13:41