[ET-VK] Fix squeeze_copy of the outermost dim under dynamic shapes

[msluszniak]

Summary

add_squeeze_copy_dims_node() deliberately skips dim 0 and falls back to add_clone_node(). But resize_clone_node() only propagates sizes when input and output have the same dim count -- which a squeeze never does, and the code says so:

// TODO: support for when dimensionality doesn't match, i.e. clone is used to
// implement squeeze.
if (graph->dim_of(out) == graph->dim_of(in)) {
  graph->virtual_resize(out, graph->sizes_of(in));
}

So the output is never resized. With static shapes that is invisible. With dynamic shapes the output keeps its upper-bound extents while consumers read it at the real size, the copy lands in the wrong places, and roughly half the output comes back zeroed. There is no error; the values are just wrong.

op_registry.py declares supports_resize=True for squeeze_copy.dims, so the partitioner accepts the op and the result is a silent wrong answer rather than a rejected partition.

Fix

Route dim 0 through the permute path like every other squeeze dim. resize_permute_node() already has an explicit branch for the rank-reducing case, so no new resize logic is needed.

Reproduction

Any model that ends up with torch.cat(list(x), -1) over a rank-4 tensor with a dynamic dim: the unbind lowers to slice_copy + squeeze_copy.dims, and the second slice comes back zeroed for every extent below the bound. Reduced:

class M(torch.nn.Module):
    def forward(self, y):
        return y[1:2], y[1:2].squeeze(0)

ep = torch.export.export(M(), (torch.randn(2, 2, 1000, 128),),
                         dynamic_shapes=({2: Dim("L", min=8, max=1000)},))

At L=200, y[1:2] is correct while y[1:2].squeeze(0) returns exactly half zeros -- cosine 0.704 against the reference, which is sqrt(0.5). It is correct only at L=1000, the bound.

Verification

Galaxy S26 Ultra, Adreno 840, fp16:

case	before	after
y[1:2].squeeze(0), L=200 / 500 / 1000	0.704 / 0.708 / 1.000000	1.000000 at all three
TTS model, CFG batch built via cat(list(x), -1)	0.36	0.99993

The second row is a supertonic TTS vector-estimator whose classifier-free-guidance uncond branch was the zeroed slice; it is now within fp16 noise of its CPU reference at every sequence length tested (64, 200, 500, 1000).

Note that this class of bug is invisible to executor_runner, which can only run a model at its dynamic upper bound -- there is no flag to request a smaller shape, and --inputs files must match nbytes() of the bound. I found it with a local patch adding an --input_shapes flag; happy to send that separately if it would be useful.

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

⚠️ 15 Awaiting Approval

As of commit a4629cf with merge base 39d623e ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build documentation (gh)
• Build Presets (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test Cortex-M Backend (gh)
• Test NXP Backend (gh)
• Test QNN Backend (gh)
• Test QNN Windows MSVC build (gh)
• Test Vulkan Backend (gh)
• Test Vulkan Backend (specialized runners) (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

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

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.