Arm backend: Decompose integral float pow exponents

[usamahz]

Treat positive integral float scalar exponents like integer exponents in DecomposeIntPowPass. This avoids lowering pow(x, 2.0) to TOSA POW, whose reference model rejects negative bases even when the exponent is mathematically integral.

Test Plan:

• lintrunner on changed files
• pytest test_decompose_int_pow_pass.py
• TinySwin2SR FP/INT TOSA reference smoke

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/19693

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

• Run pull request jobs on OSDC runners in shadow mode

❌ 1 New Failure

As of commit ee2d949 with merge base b4a9e72 ():

NEW FAILURE - The following job has failed:

• pull / test-coreml-bc-macos (macos-m1-stable) / 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.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[zingo]

Some tests fails that needs to be handled before merge. Ill rerun all tests to see if it was a random error

[usamahz]

@claude review this PR

[claude]

Claude finished @usamahz's task in 1m 35s —— View job

---

Review of PR #19693

• Gather context and read changed files
• Analyze the implementation
• Post review feedback

---

Overall: This is a clean, well-scoped PR. The change is conservative, solves a real problem, and has appropriate test coverage.

Summary

The PR extends DecomposeIntPowPass to treat positive integral float exponents (e.g., 2.0) the same as integer exponents, decomposing them into a chain of multiplications. This avoids lowering pow(x, 2.0) to TOSA POW, which rejects negative bases—even when the exponent is mathematically integral and the result is well-defined.

What works well

1. Conservative scope — only positive integral floats are decomposed. Zero and negative float exponents are intentionally left on their existing paths, avoiding behavioral changes in untested areas.

2. Correct boundary handling — float.is_integer() is the right check for IEEE 754 exactness. The exp == 0 check at line 47 correctly catches 0.0 (since 0.0 == 0 is True in Python), so the zero-handling branch is unaffected.

3. Good negative tests — non_integer_float_test_data with 1.999999999 and 2.000000001 verifies that near-integer floats are NOT decomposed, which is critical for correctness (rounding would silently change fractional pow semantics for negative bases).

4. xfails removed — the test_pow.py cleanup follows naturally: the "exp_two" case (base = torch.randn(...) which can be negative, exponent = 2.0) is now decomposed to mul and no longer hits the TOSA constraint.

Minor observations (non-blocking)

1. Asymmetry between int and float negative exponents (decompose_int_pow_pass.py:32): Integer -2 is decomposed (via the exp < 0 branch at line 63), but float -2.0 is not (returns None from the helper). The commit message explains this is intentional to keep existing paths unchanged. Worth a follow-up if TOSA also rejects negative bases with -2.0 exponent in practice—but fine to defer.

2. Large float exponents (e.g., 1000000.0): These would produce very long mul chains (999,999 ops), same as the existing integer path. The existing comment on line 71 acknowledges this debt. Not a regression from this PR.

3. Type annotation (decompose_int_pow_pass.py:25): The exp parameter is untyped. A Union[int, float] annotation would make the contract explicit, though this matches the existing style of the file.

Verdict

Looks good to merge once the unrelated CI failure (test_channels_last_tagged_reshape.py) is confirmed as unrelated (it's in backends/xnnpack, not arm). The implementation is correct and the tests cover the important edge cases.

---