[abm-77]

Summary

The int64 narrowing passes predate EXT-INT64 and narrow even when the spec declares int64. This makes them consult the spec. Narrowing stays the default and is unchanged for existing spec strings; int64 is kept only when a spec asks for it.

keeps_int64() requires the INT profile and the extension, and gates the dtype mapping, narrowing passes, dialect validators and node visitors. TOSA_EXT_INT64_SupportList lists the operators the extension covers, alongside the other TOSA_EXT_*_SupportList lists. An operator absent from it narrows exactly as it does today, so ops the extension leaves out (clamp, matmul) and ops whose decomposition narrows (div.Tensor_mode, remainder) fall back to CPU instead of failing during serialization. int64 casts are restricted to bool and i32, and an operator with mixed int64/int32 operands falls back rather than reaching a validator requiring matching dtypes.

TOSA 1.1 is draft and EXT-INT64 is Experimental there, so it may change. TOSA-1.1+FP+int64 is unchanged, since the FP path never lowered int64. Follow-ups: FP+int64, and reductions over all axes.

Happy to split this up or rework it however the maintainers prefer.

Fixes #24095

Test Plan

• backends/arm/test/misc/test_int64.py: 14 pass, covering int64 add, sub, mul, a scalar comparison above 2**53, and matched and mixed-width SELECT.
• backends/arm/test/passes: 1049 pass, same failures as base.
• 44 single-op models: identical to base under TOSA-1.0+INT; under TOSA-1.1+INT+int64 no narrowing casts and no errors.
• TOSA-1.1+FP+int64 against base TOSA-1.1+FP: identical.

This PR was authored with Claude Code.

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

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 6 New Failures, 9 Unrelated Failures

As of commit 514dcee with merge base 0295293 ():

NEW FAILURES - The following jobs have failed:

• trunk / test-models-macos-coreml (ic3) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (ic4) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (mobilebert) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (mv3) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (resnet50) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (vit) / macos-job (gh)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

• trunk / test-models-macos-coreml (mv2) / macos-job (gh) (similar failure)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (w2l) / macos-job (gh) (similar failure)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1

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

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

• Apple / build-demo-ios / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 1
• trunk / test-coreml-delegate / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/runner/work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (dl3) / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (edsr) / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (efficient_sam) / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (emformer_join) / macos-job (gh) (trunk failure)
  RuntimeError: Command bash /Users/ec2-user/runner/_work/_temp/exec_script failed with exit code 1
• trunk / test-models-macos-coreml (emformer_transcribe) / macos-job (gh) (trunk failure)
  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.

[meta-cla]

Hi @abm-77!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: abm-77 / name: Bryson (012f37f, 3e71137, 7930bc9, 92efc39, a387f1b, b8098b2, b866d99, bf72310, e2f8d86, ef7b404)

[pytorch-bot]

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

[abm-77]

@pytorchbot label "release notes: arm"

[Copilot]

🟡 Changes recommended

Unresolved extension-handling gaps still cause unwanted narrowing, lowering failures, and CPU fallback for supported int64 operations.

4 open issues

• Honor supplied TOSA spec for INT64 reduction paths · New
• Enable INT64 BITWISE_AND lowering through binary operator factory · New
• Allow extension-supported INT64 tensors through layout lowering · New
• Support INT64 WHERE branches under the extension gate · New

What changed in this PR

This PR addresses #24095 by making the Arm backend preserve int64 tensors when the TOSA specification declares the int64 extension.

Changes:

• Gate int64 narrowing passes on extension support.
• Enable INT64 mapping and extension-aware validation across dialect operations and node visitors.
• Add lowering cases for int64 arithmetic and scalar comparison.

File	Description
backends/​arm/​tosa/​specification.py	Add a context-based extension check.
backends/​arm/​tosa/​mapping.py	Map INT64 and validate extension support.
backends/​arm/​tosa/​dialect/​ops/​unary_elementwise.py	Allow extension-gated int64 unary operations.
backends/​arm/​tosa/​dialect/​ops/​ternary_elementwise.py	Allow int64 SELECT values.
backends/​arm/​tosa/​dialect/​ops/​comparison.py	Allow int64 comparisons.
backends/​arm/​tosa/​dialect/​ops/​binary_elementwise.py	Allow int64 arithmetic and min/max validation.
backends/​arm/​test/​misc/​test_int64.py	Add int64-extension lowering cases.
backends/​arm/​operators/​simple_node_visitor.py	Support extension-gated input dtype lists.
backends/​arm/​operators/​operator_validation_utils.py	Include INT64 in supported layout dtypes.
backends/​arm/​operators/​op_where.py	Accept extension-gated INT64 values.
backends/​arm/​operators/​op_tosa_sub.py	Enable INT64 subtraction.
backends/​arm/​operators/​op_tosa_reduce_sum.py	Enable INT64 sum visitor validation.
backends/​arm/​operators/​op_tosa_reduce_min.py	Enable INT64 minimum reduction validation.
backends/​arm/​operators/​op_tosa_reduce_max.py	Enable INT64 maximum reduction validation.
backends/​arm/​operators/​op_tosa_neg.py	Enable INT64 negation.
backends/​arm/​operators/​op_tosa_mul.py	Enable INT64 multiplication validation.
backends/​arm/​operators/​op_tosa_minimum.py	Enable INT64 elementwise minimum.
backends/​arm/​operators/​op_tosa_maximum.py	Enable INT64 elementwise maximum.
backends/​arm/​operators/​op_tosa_identity.py	Enable INT64 identity.
backends/​arm/​operators/​op_tosa_gt.py	Enable INT64 greater-than operands.
backends/​arm/​operators/​op_tosa_ge.py	Enable INT64 greater-or-equal operands.
backends/​arm/​operators/​op_tosa_eq.py	Enable INT64 equality operands.
backends/​arm/​operators/​op_tosa_bitwise_not.py	Enable INT64 bitwise NOT.
backends/​arm/​operators/​op_tosa_add.py	Enable INT64 addition.
backends/​arm/​operators/​op_tosa_abs.py	Enable INT64 absolute value.
backends/​arm/​operators/​op_flip.py	Enable INT64 flip validation.
backends/​arm/​_passes/​insert_int32_casts_after_int64_placeholders.py	Skip placeholder narrowing with the extension.
backends/​arm/​_passes/​convert_int64_output_ops_to_int32.py	Guard output narrowing with an extension check.
backends/​arm/​_passes/​convert_int64_const_ops_to_int32.py	Skip constant-operation narrowing with the extension.
backends/​arm/​_passes/​cast_int64_pass.py	Skip buffer narrowing with the extension.

_{Review effort: Balanced}

[nil-is-all]

Thanks for filing the bug report and the PR, @abm-77. As we wait on Arm maintainers to review, could you sign the CLA?

[Copilot]

🟡 Changes recommended

Scalar precision loss and inconsistent partitioner checks can cause incorrect results or lowering failures, while the new tests do not verify int64 preservation.

4 open issues

• Preserve large integer scalar precision during materialization · New
• Allow extension-supported INT64 tensors through layout lowering
• Accept extension-enabled int64 slices independently of INT profile · New
• Allow extension-enabled int64 where comparisons independently of INT profile · New

3 previously missed issues

In code that hasn't changed since last review

Reject unsupported int64 bitwise operators during partitioning

backends/​arm/​_passes/​insert_int32_casts_after_int64_placeholders.py:120

Skipping placeholder narrowing lets unsupported int64 operators reach lowering. Under TOSA-1.1+INT+int64, BoolBitwiseSupported accepts int64 x | y, but the BITWISE_OR dialect validator and visitor only accept int8/int16/int32. Lowering then raises instead of leaving the operation on the portable path; BITWISE_XOR has the same mismatch. Keep the narrowing skip, but reject these unsupported dtype/operator combinations during partitioning, or implement int64 lowering where the TOSA specification permits it.

Assert delegation and preservation of INT64 operands

backends/​arm/​test/​misc/​test_int64.py:158

These cases only check that conversion completes; they do not assert delegation or preserved INT64 operands. They can therefore pass if the operators fall back to CPU or are silently narrowed. The small inputs would also hide narrowing in an output comparison. Assert that the expected operators delegate and retain INT64 operands, including the inputs to GREATER whose output is BOOL. Alternatively, assert delegation and compare execution results using values outside the int32 range.

Allow extension-enabled int64 comparison inputs in negative checks

backends/​arm/​tosa/​dialect/​ops/​comparison.py:44

The dialect now accepts int64 comparisons under TOSA-1.1+FP+int64, but _floating_profile_negative_checks() still installs CheckFPComparisonInputs whenever the INT profile is absent. That check rejects int64 inputs, so eq/gt/ge with int64 placeholders remain undelegated under this valid spec. Pass the specification to the negative check and allow extension-enabled int64 comparison inputs while preserving rejection for specs without the extension.

3 resolved since last review

• Enable INT64 BITWISE_AND lowering through binary operator factory
• Honor supplied TOSA spec for INT64 reduction paths
• Support INT64 WHERE branches under the extension gate

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Retained int64 OR/XOR operands can fail during lowering, and the new tests do not verify delegation or int64 preservation.

4 open issues

• Reject unsupported INT64 bitwise OR/XOR delegation · New
• Preserve large integer scalar precision during materialization
• Allow extension-enabled int64 where comparisons independently of INT profile
• Accept extension-enabled int64 slices independently of INT profile

1 previously missed issue

In code that hasn't changed since last review

Add delegation, operator, and INT64 preservation assertions

backends/​arm/​test/​misc/​test_int64.py:158

This chain checks only that lowering completes. It still passes if every operation falls back to CPU or if tensors are narrowed to int32; it neither asserts delegation nor executes or inspects the lowered computation. Add delegate-count and no-leftover-operator assertions, then verify INT64 tensor dtypes in the delegated graph or compare exact outputs with width-sensitive inputs outside the int32 range. The current small inputs would not expose narrowing even if output comparison were added.

1 resolved since last review

• Allow extension-supported INT64 tensors through layout lowering

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Extension-enabled paths still have partitioning and lowering gaps, and the new tests do not verify delegation or retained precision.

4 open issues

• Prevent unsupported int64 shifts from raising · New
• Allow FP+int64 reduction validation · New
• Enable FP+int64 comparison delegation · New
• Assert delegation and int64 precision in tests · New

4 resolved since last review

• Reject unsupported INT64 bitwise OR/XOR delegation
• Preserve large integer scalar precision during materialization
• Allow extension-enabled int64 where comparisons independently of INT profile
• Accept extension-enabled int64 slices independently of INT profile

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Newly accepted mixed-width WHERE operands can still narrow int64 values to int32 and lose precision.

4 open issues

• Preserve mixed-width WHERE operands without lossy casts · New
• Enable FP+int64 comparison delegation
• Allow FP+int64 reduction validation
• Prevent unsupported int64 shifts from raising

1 resolved since last review

• Assert delegation and int64 precision in tests

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Accepted decompositions can still lose int64 values or fail lowering, and mixed-profile cast validation permits unsupported conversions.

2 open issues

• Reject int64 division and activation decompositions that lose precision · New
• Filter disallowed int64 casts after profile extension additions · New

2 resolved since last review

• Reject or lower unsupported INT64-to-INT8/INT16 casts
• Reject unsupported int64 Tensor shifts during partitioning

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Retained-int64 lowering still mishandles explicit SUM dtypes and admits matrix multiplications that fail instead of falling back to CPU.

2 open issues

• Reject int64 mm and bmm before unsupported MATMUL lowering · New
• Preserve requested dtype when lowering integer reductions · New

2 resolved since last review

• Filter disallowed int64 casts after profile extension additions
• Reject int64 division and activation decompositions that lose precision

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Widening sums can accumulate at the wrong width, while mixed-width comparisons and int64 ARGMAX inputs can fail lowering instead of falling back.

3 open issues

• Preserve int64 widening for integer sum reductions · New
• Reject int64 ARGMAX inputs despite explicit output casts · New
• Promote or reject mixed-width int64 comparison operands · New

2 resolved since last review

• Preserve requested dtype when lowering integer reductions
• Reject int64 mm and bmm before unsupported MATMUL lowering

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Mixed-width binary operations and gather-based paths can still pass partitioning and then fail lowering instead of falling back to CPU.

2 open issues

• Reject unsupported INT64 gather and embedding inputs · New
• Reject unsupported mixed-width binary operators · New

3 resolved since last review

• Preserve int64 widening for integer sum reductions
• Promote or reject mixed-width int64 comparison operands
• Reject int64 ARGMAX inputs despite explicit output casts

_{Review effort: Balanced}

[abm-77]

Drafting while I work to refactor the design.