[MLX] Add aten.bitwise_or op handler

[devin-lai]

Summary:

• Add an MLX schema node and op handler for aten.bitwise_or Tensor and Scalar overloads.
• Execute the node through MLX bitwise_or in the runtime interpreter.
• Add bool, integer, and scalar op test coverage.

Fixes #18926.

Testing:

• cmake --build cmake-out-mlx --target op_test_runner -j2
• PATH="$PWD/.venv-mlx/bin:$PATH" .venv-mlx/bin/python -m executorch.backends.mlx.test.run_all_tests bitwise_or_bool bitwise_or_int bitwise_or_scalar --timeout 180
• cmake --build cmake-out-mlx --target strict_compile_test -j2
• git diff --check
• py_compile on changed Python files
• lintrunner --take FLAKE8,CLANGFORMAT,NEWLINE,ETCAPITAL,LICENSELINT on touched files

cc @metascroy

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 1 Cancelled Job, 2 Unrelated Failures

As of commit ab83bbb with merge base 37effad ():

CANCELLED JOB - The following job was cancelled. Please retry:

• pull / test-models-linux (phi_4_mini, portable, linux.4xlarge.memory) / linux-job (gh)
  ##[error]The operation was canceled.

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

• MLX / test-mlx-voxtral-realtime / test-mlx-voxtral-realtime (gh) (detected as infra flaky with no log or failing log classifier)
• pull / test-qnn-testsuite-linux / test-backend-linux (qnn, models) / linux-job (gh) (detected as infra flaky with no log or failing log classifier)

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

[devin-lai]

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.

@pytorchbot label "release notes: apple"

[nil-is-all]

@claude review

[claude]

Claude finished @nil-is-all's task in 2m 43s —— View job

---

Code Review: [MLX] Add aten.bitwise_or op handler

• Read changed files and gather context
• Review backends/mlx/ops.py changes
• Review backends/mlx/runtime/MLXInterpreter.h changes
• Review backends/mlx/serialization/schema.fbs changes
• Review backends/mlx/test/test_ops.py changes
• Post review feedback

---

Verdict: Looks good. This is a clean, well-structured addition that follows the exact same pattern as the existing bitwise_and op. No issues found.

Details

Schema (schema.fbs):

• BitwiseOrNode table correctly mirrors the BitwiseAndNode structure with a, b, and out fields
• Appended to the OpNode union at the end (respecting backward compatibility rules)

Runtime (MLXInterpreter.h):

• exec_bitwise_or follows the identical pattern as exec_bitwise_and — delegates directly to MLX's bitwise_or
• Dispatch case OpCode::BITWISE_OR correctly wired up in the switch statement

Python ops (ops.py):

• Registers both Tensor and Scalar overloads via the _BINARY_OPS table with has_scalar=True
• Correctly imports BitwiseOrNode from the generated schema

Tests (test_ops.py):

• bitwise_or_bool and bitwise_or_int cover Tensor-Tensor via the _BINARY_OP_TESTS table
• BitwiseOrScalarTest covers the Scalar overload with bool, int32, and int64 dtypes
• Test structure is identical to the existing BitwiseAndScalarTest

No correctness, performance, or compatibility concerns. The implementation correctly leverages MLX's native bitwise_or which handles broadcasting, and the scalar variant is handled by the framework's existing _BINARY_OPS infrastructure that wraps scalars into tensors before calling the op.

---

[metascroy]

LGTM...let's see what CI says

[pytorch-bot]

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

[metascroy]

@devin-lai it looks like [MLX / backend-tester (models) / test-mlx-backend-models (push)] is failing. Can you have a look at why?

[devin-lai]

@devin-lai it looks like [MLX / backend-tester (models) / test-mlx-backend-models (push)] is failing. Can you have a look at why?

ok. I checked the logs for the failing push run. The job failed because the MLX model suite allows up to 3 failures, but this run had 4

The 3 failures that also appear in the passing PR-triggered run are:

• test_conformer[mlx-static_shapes-float32]
• test_swin_v2_t[mlx-static_shapes-float32]
• test_swin_v2_t[mlx-dynamic_shapes-float32]

The extra failure in the push run is:

• test_inception_v3 [mlx-dynamic_shapes-float32]

That one failed with a numerical output mismatch, not with a missing op, serialization issue, or anything obviously related to the bitwise_or change. The same SHA passed the PR-triggered MLX backend-models job with exactly 3 failures, and the MLX operator job passed.

This looks like a flaky/threshold-sensitive MLX model-suite failure rather than a regression from this PR. I tried to rerun the failed push job directly, but GitHub requires admin rights on pytorch/executorch. Could someone with permission rerun the failed job/run? If it reproduces, I can help look into the Inception V3 dynamic-shape case separately

[metascroy]

@devin-lai it looks like [MLX / backend-tester (models) / test-mlx-backend-models (push)] is failing. Can you have a look at why?

ok. I checked the logs for the failing push run. The job failed because the MLX model suite allows up to 3 failures, but this run had 4

The 3 failures that also appear in the passing PR-triggered run are:

• test_conformer[mlx-static_shapes-float32]
• test_swin_v2_t[mlx-static_shapes-float32]
• test_swin_v2_t[mlx-dynamic_shapes-float32]

The extra failure in the push run is:

• test_inception_v3 [mlx-dynamic_shapes-float32]

That one failed with a numerical output mismatch, not with a missing op, serialization issue, or anything obviously related to the bitwise_or change. The same SHA passed the PR-triggered MLX backend-models job with exactly 3 failures, and the MLX operator job passed.

This looks like a flaky/threshold-sensitive MLX model-suite failure rather than a regression from this PR. I tried to rerun the failed push job directly, but GitHub requires admin rights on pytorch/executorch. Could someone with permission rerun the failed job/run? If it reproduces, I can help look into the Inception V3 dynamic-shape case separately

Re-running CI. Let's see if it passes now.

[metascroy]

Looks like it passes now. Thanks for the contribution @devin-lai!