Transforms: scope duplicate-user fusion for layout propagation

[rascani]

Summary

Layout propagation uses FuseDuplicateUsersPass to merge duplicate view and permute users exposed while transforms move through a graph.

This PR adds two optional controls:

• allowed_targets limits fusion to the layout-copy operators owned by propagation.
• semantic_key includes backend metadata not represented in FX arguments.

Arm uses the semantic key for input and output qparams, preventing otherwise-identical layout copies with different
quantization semantics from being merged.

Existing callers retain their current behavior. This PR does not change the generic pass’s handling of mutation, aliasing, effects, literals, or graph outputs. Arm’s existing RESCALE exclusion and output cleanup also remain unchanged.

Review guide

1. fuse_duplicate_users_pass.py: the two optional configuration points.
2. propagate_view_copy_permute_pass.py: restricting fusion to layout copies.
3. Arm propagation: adding qparams to the semantic key.
4. Tests: distinct qparams remain distinct and unrelated duplicate users are ignored.

AI-assisted: Codex.

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

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

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

✅ No Failures

As of commit 871143b with merge base 684d4bd ():
💚 Looks good so far! There are no failures yet. 💚

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

[AdrianLundell]

This patch does at least 5 different things, would it be possible to split it or at least document it a bit to help the review?

[rascani]

This patch does at least 5 different things, would it be possible to split it or at least document it a bit to help the review?

Sorry about that. It does a lot, but I'd prefer not to split it because its all related to making a safe decision about whether two nodes can share the same output. I've updated the summary to (hopefully) better explain what it is doing and also included a suggested review order.

[AdrianLundell]

The operator is nondeterministic / equal-looking literal tensors are different objects. -> Seems reasonable but how often are literal tensors and non deterministic ops users of previous ops? Could the relevant ops be listed for simplicity?

Operator is mutable, or returns an alias. / An effect occurs between the two calls. / One result, or an alias of it, is later mutated. -> All of these are about aliasing and muteability, do we handle such cases usually and would this not be an issue for all decompositions in that case? Also, the code is a bit complex, could it be simplified by just doing one pass of marking nodes which are mutated by another node and directly bailing on them or is there any case which is missed?

Both results are independently returned. -> Could this be simplified by just not fusing nodes which are inputs to the output node or am I missing some subtlety?

Backend metadata changes the meaning of the operation. -> OK