[EXIR] Register _clone_dim_order op and map aten.clone

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.

[keyprocedure]

Summary

This is PR 2 of 3 implementing a dim order aware clone op.

This PR registers the new _clone_dim_order op and maps aten.clone to dim_order_ops._clone_dim_order in EXIR during export to preserve memory layout changes (contiguous/channels_last). It also updates the Core ML, ARM, and Qualcomm backends to handle the new clone op.

Related PRs:

• PR 1: #12974 - Add _clone_dim_order portable kernel
• PR 3: #12976 - Update RemoveCloneOpsTransform to be dim order aware

Fixes#12645

Test plan

• Operator level tests to verify kernel behavior for layout preservation and changes.
• Graph level checks to confirm that clone mapping occurs.
• End to end tests to validate that functional clone behavior is unchanged.
• Backend tests to ensure clone semantics are preserved.

All tests pass via:
python -m unittest exir.tests.test_memory_format_ops_pass
python -m unittest backends.apple.coreml.test.test_torch_ops
pytest backends/arm/test/ops/test_clone.py
pytest backends/arm/test/passes/test_remove_clone_pass.py

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 30a1d13 with merge base 32e82bc ():

NEW FAILURES - The following jobs have failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold
• pull / unittest / macos / macos-job (gh)
  backends/xnnpack/test/ops/test_rsqrt.py::TestRsqrt::test_fp16_rsqrt
• trunk / test-selective-build-macos (cmake) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

[keyprocedure]

@pytorchbot label "release notes: none"

[keyprocedure]

@Gasoonjia I could use your input on the Qualcomm backend changes:

After replacing edge.aten.clone with edge.dim_order_ops._clone_dim_order in QNN, I was able to successfully run all the previously failing QNN tests on a local Linux machine.

Should _clone_dim_order always be treated as a non-delegated op, like clone was?

I set the clone op removal condition to the default value (True) instead of checking if dim order is non-contiguous.

I also didn't create a node visitor or add an operator test in test_qnn_delegate since the op wouldn't be delegated and would fail the delegated partitioner count test.

[Gasoonjia]

Hi @keyprocedure , thanks for your great work and ci has been triggered!

Yes we can treat the dim order variant copy as non-delegated, just as what we are doing for aten::copy.

cc. @digantdesai

[keyprocedure]

Happy to help!
Sounds good, really appreciate your responsiveness.

[keyprocedure]

@Gasoonjia CI failures are unrelated. If everything looks good to you, I can commit the test_torch_ops.py merge conflict fix.

[Gasoonjia]

@keyprocedure lgtm. Please solve the conflict and then I will stamp it!

[keyprocedure]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

To add the ciflow label ciflow/trunk please first approve the workflows that are awaiting approval (scroll to the bottom of this page).

This helps ensure we don't trigger CI on this PR until it is actually authorized to do so. Please ping one of the reviewers if you do not have access to approve and run workflows.

[Gasoonjia]

@keyprocedure i think it is fine for us right now, and we can work on coreml side later.

@metascroy do you have any concerns on this?

[metascroy]

LGTM

[metascroy]

@Gasoonjia the merge conflict is resolved.

I noticed that coreml's torch_ops.py has updated the way it registers _empty_dim_order and _to_dim_order_copy. Since _clone_dim_order hasn't been registered in Apple's dim_order_ops.py yet, are the current changes in torch_ops.pysufficient for now?

Yes, the changes in torch_ops.py should be sufficient. The purpose of torch_ops.py is to register ops that are not yet in coremltools. With that said, we generally prefer that you put up a PR in coremltools and link that PR in a comment above the op you're creating in toch_ops.py. You can see this for most other ops in the file, e.g.,

executorch/backends/apple/coreml/compiler/torch_ops.py

Line 39 in 82991b5

# https://github.com/apple/coremltools/pull/2557

[Gasoonjia]

Thanks @metascroy 's comment! Let me stamp this PR for now and we can add coreml PR later.