[abm-77]

Summary

Adds TOSA_EXT_INT64_SupportList, the operators EXT-INT64 covers, and delegates int64 only to those. Today the int64 check is skipped entirely when the extension is declared, so an operator that cannot carry int64 is accepted and fails later, for example cumsum under TOSA-1.1+INT+int64. An operator absent from the list now keeps the behavior it has without the extension. Comparisons, where, slice_copy, full_like and zeros_like stay off the list until part 3. Scoped to PRO-INT + EXT-INT64, as discussed in #24128.

Part 2 of 3 for #24095, following #24128.

Test Plan

Added partitioning tests under TOSA-1.1+INT+int64: a listed operator on int64 operands delegates, while unlisted operators and mixed-width operands fall back to CPU. Eight of these cases fail on main. 44 single-op models: identical to main under TOSA-1.0+INT, and under TOSA-1.1+INT+int64 cumsum falls back instead of failing and sum_dim falls back as it does without the extension.

This PR was authored with Claude Code.

cc @zingo @YufengShi-dudu

[pytorch-bot]

🔗 Helpful Links

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

• 📄 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:

• Investigating a potential degradation on Meta's CI clusters

❌ 4 New Failures, 1 Pending

As of commit 6b44cef with merge base a0a365b ():

NEW FAILURES - The following jobs have failed:

• pull / nxp-mcuxpresso-test / linux-job (gh)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 1
• pull / unittest-buck / linux / linux-job (gh)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 3
• pull / unittest-buck / macos / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 3
• trunk / test-models-linux-aarch64 (linear, portable, mt-l-arm64g4-16-62) / linux-job (gh)
  executorch

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

[pytorch-bot]

Workflows were awaiting approval. CI has now been triggered for the ciflow labels on this PR.

[Copilot]

🟡 Changes recommended

Mixed-width cat and bool/int64 where are incorrectly accepted, causing lowering failures or unsupported casts instead of safe fallback.

2 open issues

• Handle mixed-dtype torch.cat operands in int64 exemption · New
• Reject mixed bool/int64 torch.where value operands · New

What changed in this PR

This second part of the Arm int64 work restricts delegation under PRO-INT + EXT-INT64 to operators with supported lowerings, while retaining existing checks for unlisted operators.

Changes:

• Adds an EXT-INT64 operator allowlist and operand-width checks.
• Enables int64 eligibility for where and slice_copy under the supported profile.
• Adds partitioning tests for accepted operations and CPU fallback cases.

File	Description
backends/​arm/​tosa/​specification.py	Adds the shared keeps_int64 profile check.
backends/​arm/​test/​misc/​test_int64.py	Adds int64 delegation and fallback tests.
backends/​arm/​operator_support/​where_support.py	Allows int64 values with the extension.
backends/​arm/​operator_support/​tosa_supported_operators.py	Applies the allowlist and operand-width guard.
backends/​arm/​operator_support/​tosa_profile_supported_op_lists.py	Defines the EXT-INT64 operator allowlist.
backends/​arm/​operator_support/​slice_copy_support.py	Adds conditional int64 eligibility for slicing.

_{Review effort: Balanced}

[abm-77]

@pytorchbot label "release notes: arm"

[Copilot]

🟡 Changes recommended

Dynamic views with symbolic shapes can crash partitioning, while mixed bool/int64 where operands can produce an unsupported cast that the current tests fail to exercise.

2 open issues

• Filter symbolic shape metadata before collecting tensor dtypes · New
• Reject mixed bool and int64 where operands · New

2 resolved since last review

• Reject mixed bool/int64 torch.where value operands
• Handle mixed-dtype torch.cat operands in int64 exemption

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The int64 support checks omit supported padding operations and incorrectly accept mixed bool/int64 concatenation, causing unnecessary CPU fallback and a lowering error, respectively.

No open issues 🎉

2 previously missed issues

In code that hasn't changed since last review

Add pad entry points to int64 partitioning

backends/​arm/​operator_support/​tosa_profile_supported_op_lists.py:396

This list omits aten.pad.default and aten.constant_pad_nd.default, so padding an int64 user tensor now falls back to CPU under TOSA-1.1+INT+int64. Constant padding lowers to PAD, whose dialect validator and visitor already accept int64 with the extension. Include both padding entry points and add a partitioning regression case.

Preserve bool data operands in int64 cat partitioning

backends/​arm/​operator_support/​tosa_supported_operators.py:1217

Removing torch.bool from every operand set accepts torch.cat([x_int64, flags_bool]) under TOSA-1.1+INT+int64. Its inputs are not promoted on the INT path, so CONCAT lowering raises a dtype-mismatch error instead of falling back. Exclude only the where condition, retain boolean data operands, and add a mixed bool/int64 cat regression case.

2 resolved since last review

• Reject mixed bool and int64 where operands
• Filter symbolic shape metadata before collecting tensor dtypes

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human review is needed because the int64 allowlist changes conflict with comparison lowering and operator-preservation requirements, causing export failures and delegation contract violations.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human assessment is needed because the int64 support changes admit slices and comparisons that fail lowering while rejecting a supported shape operation.

No open issues 🎉

_{Review effort: Balanced}

[nil-is-all]

Running CI tests. @YufengShi-dudu & @zingo assigned to you since you reviewed the previous PR

[YufengShi-dudu]

Could you explain how this list was derived and what criteria were used to select the operators? It’s fine if Claude Code helped generate it; we can refine the list internally later.

[abm-77]

Sure. I built it with Claude Code from tosa.xml in the TOSA 1.1 spec. I started from the operators with an i64 row under EXT-INT64 and kept the edge operators that lower only to those, through the visitors #24128 enabled int64 on. I then lowered each one under TOSA-1.1+INT+int64 with values outside the int32 range. Going back over it for your other comment, I also took off the comparisons, full_like and zeros_like. Without quantization the comparisons fail in CastIntComparisonInputsPass, on main as well, and full_like and zeros_like hit the same buffer narrowing as where. They fall back now, and I'll add them back in the next PR. I also fixed the comment above the list, which said EXT-INT64 leaves out ARGMAX.

[YufengShi-dudu]

Could we address the buffer-narrowing interaction before enabling these INT64 paths (slice_copy and where)? Under TOSA-1.1+INT+int64, the newly accepted operations still encounter CastInt64BuffersToInt32Pass:

• x[::2] on a five-element INT64 tensor creates an internal padding buffer that gets narrowed to INT32, causing a CONCAT dtype mismatch.
• torch.where(cond, x, self.buffer), with a registered INT64 buffer containing 2**40, fails the pass’s INT32 range check.

Both cases previously exported successfully with CPU fallback.

A small fix would be to defer the new INT64 dtype allowances in WhereSupported and SliceCopySupported until the buffer-preservation changes land. We could update the where_int64 expectation and add regression tests confirming these cases export successfully without delegation. Alternatively, we could bring the necessary buffer-preservation fix into this PR.

[abm-77]

Thanks, I went with deferring them. WhereSupported and SliceCopySupported are back to main, and where and slice_copy are off the int64 list until the buffer changes land in the next PR. Both of your cases export with CPU fallback now, and I added them as regression tests. I also changed the where_int64 case to expect fallback.

[Copilot]

🔵 Needs a closer look

Human assessment is needed because inconsistent delegation of dynamic int64 shape producers and consumers can leave an unserializable SymInt at the delegate boundary.

No open issues 🎉

_{Review effort: Balanced}