Fix unsafe copies in EXIR and permute transforms

[oscarandersson8218]

Replace deepcopy-based copies of shape lists with shallow container copies in paths that can carry torch.SymInt values from fake tensor metadata. This is safe as torch.Size is immutable, so creating a shallow list copy of it is safe: we can insert/delete elements in the new list without affecting the original shape.

This fixes symbolic-shape failures in exir.tensor.stride_from_dim_order() and in PostponePermuteOpBelowSqueezeOrUnsqueezeLikeView, where deepcopy() could crash while handling SymInt-backed shapes. The error that was produced: "RuntimeError: Cannot access data pointer of Tensor (e.g. FakeTensor, FunctionalTensor). If you're using torch.compile/export/fx, it is likely that we are erroneously tracing into a custom kernel. To fix this, please wrap the custom kernel into an opaque custom op. Please see the following for details:
https://pytorch.org/tutorials/advanced/custom_ops_landing_page.html"

Add focused regression coverage for both cases: one test for stride computation with symbolic sizes, and one dynamic-shape edge-graph test for the permute/view transform pass.

cc @digantdesai @freddan80 @per @zingo @mansnils @Sebastian-Larsson @robell @rascani

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• [ROCm] MI350 CI jobs will have longer queue times due to CI migration

❌ 1 New Failure, 1 Cancelled Job, 3 Unrelated Failures, 2 Unclassified Failures

As of commit 8807bdc with merge base 1a78804 ():

NEW FAILURE - The following job has failed:

• trunk / unittest-release / macos / macos-job (gh)
  export/tests/test_target_recipes.py::TestTargetRecipes::test_vit_model

UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:

• periodic / test-models-linux (buck2, mv3, xnnpack-quantization-delegation, linux.2xlarge, 90) / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  An error occurred trying to start process '/usr/bin/bash' with working directory '/home/ec2-user/actions-runner/_work/executorch/executorch/pytorch/executorch'. No such file or directory
• trunk / test-models-macos-cpu (ic4, xnnpack-quantization-delegation) / macos-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

CANCELLED JOB - The following job was cancelled. Please retry:

• trunk / unittest-release / linux / linux-job (gh)
  ##[error]The operation was canceled.

FLAKY - The following jobs failed but were likely due to flakiness present on trunk:

• pull / test-llama-runner-qnn-linux (fp32, qnn_16a16w, qnn) / linux-job (gh) (detected as infra flaky with no log or failing log classifier)
• pull / test-qnn-testsuite-linux / test-backend-linux (qnn, models) / linux-job (gh) (matched linux rule in flaky-rules.json)
  The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

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

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

• trunk / test-llama-runner-qnn-linux (fp32, qnn_16a16w, qnn) / linux-job (gh) (trunk failure)

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

[mergennachin]

@Gasoonjia can you review this pls

[digantdesai]

@claude review this PR.

[claude]

Claude finished @digantdesai's task in 2m 22s —— View job

---

Review of PR #19873: Fix unsafe copies in EXIR and permute transforms

• Read changed files and understand the fix
• Review exir/tensor.py changes
• Review backends/transforms/postpone_permute_below_squeeze_view.py changes
• Review test files
• Post review feedback

---

Overall: This PR looks good. The fix is correct, minimal, and well-tested.

Summary

The PR replaces copy.deepcopy(...) with list(...) in two places where shape lists containing torch.SymInt values are copied before mutation. deepcopy crashes on SymInts because it tries to access the underlying tensor data pointer of the symbolic node. A shallow list copy is the right fix.

Correctness Analysis

exir/tensor.py (line 113): strides = list(sizes) — This creates a new list to hold stride values. Every element in strides is overwritten by the loop below (it never reads the initial values from sizes through strides), so a shallow copy is strictly more than needed, but correct and idiomatic.

backends/transforms/postpone_permute_below_squeeze_view.py (lines 111, 135): new_view_shape = list(pred_shape) — Here pred_shape is already a shallow list copy created at line 92 via [*cast(list, get_shape(...))]. The list() call creates another copy because new_view_shape gets mutated (.insert() / del) and pred_shape is needed intact for the other branches. The elements themselves (ints or SymInts) are never mutated — they're only read or replaced positionally — so shallow copy is semantically equivalent to the original deepcopy while being SymInt-safe.

Minor Notes

1. The import copy removal is clean — no other usages remain in either file.
2. The CI failure (Apple / build-demo-ios) appears unrelated to this change (it's a build script exit code, not a Python/shape issue).
3. Both tests are well-constructed regression tests that would have caught the original bug — they exercise torch.SymInt values flowing through the affected code paths.

Nit (non-blocking)

In test_strides_from_dim_order_with_symbolic_sizes (line 409), the expected strides [12, 4, 1] are correct because dims 1 and 2 are concrete (3, 4) even though dim 0 is symbolic. A brief comment explaining why the strides are concrete despite symbolic input could aid future readers, though this is optional per the repo's minimal-comment style.

LGTM — no blocking issues found.

---

[oscarandersson8218]

Hi @digantdesai @Gasoonjia , this has been stale for 3 weeks. Any progress on this?

[zingo]

Make sure other backends test still work.

[oscarandersson8218]

Make sure other backends test still work.

Done. All failures appear unrelated.