OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 by shoumikhin · Pull Request #24396 · pytorch/executorch

shoumikhin · 2026-11-01T02:19:43Z

What is wrong today

The OpenVINO partitioner gives min, max, amin, amax, minimum, maximum, clamp and sign to OpenVINO even when every tensor they read is bool. OpenVINO cannot convert these for bool:

ReduceMin ... Element type of data input must be numeric. Got: boolean

torch.min(x > 0, dim=1) and MultivariateNormal's argument check (PyTorch 2.15) hit this. Reading masked values after writing them fails too:

x[mask] = x[mask] * 2
return x + x[mask].sum()  # Dynamic rank for aten::index input is not supported.

What this change does

The partitioner leaves these ops to ExecuTorch's CPU kernels when every tensor they read is bool. Ops that also read a float tensor, like maximum(mask, x), stay with OpenVINO. Casting to uint8 could give wrong min(dim) and max(dim) indices on ties, as the docs now note.

For the masked read, preprocess fills each node's tensor_meta from val. OpenVINO reads ranks only from tensor_meta, which ExecuTorch leaves empty.

Follow-ups to #24294:

The test runner exits with 1 on failure (from Fix OpenVINO tests in CI #24305), and CI runs model tests even after an op test fails.
OpenVINO dropped a first input that only a folded cumsum read, failing every call. Preprocess puts it back and checks the input count.
An output planned as dynamic but compiled as fixed failed every call. Its buffer now starts with the compiled shape.
The cumsum fold works under a CUDA default device on a CPU-only PyTorch (exir's ScalarToTensorPass still fails there).
An empty last inference_precision entry now also means the default at load.
The docs say which CPUs compute some integer ops in float32, and where the float32 default is slower.

What was tested

Linux x86_64, OpenVINO 2026.4.1 and 2025.1.0, CPU, unless noted:

Op and model tests pass. The bool min model (both releases) and the masked read (2026.4.1) failed to lower, and now match eager.
On 2026.4.1, each backend fix has a test that fails without it. The runner and CI script were checked by hand.
Partitions are unchanged for every probed op with integer, float16, bfloat16 or float32 inputs, and for MobileNetV2, ResNet-18 and a transformer layer.
With the tensor_meta change, all other test partitions convert to the same OpenVINO graphs.
The docs' integer claims were measured on x86 through the delegate, and on ARM with plain OpenVINO 2026.4.1.

The OpenVINO CI job runs backends/openvino/tests/test_runner.py. When a test failed, the runner printed "completed with failures" but still exited with code 0, so the CI job stayed green and the failure went unnoticed. Now the runner exits with code 1 when any test fails, so CI turns red. Co-authored-by: suryasidd <surya.siddharth.pemmaraju@intel.com>

…d it A position cumsum such as cumsum(ones_like(input_ids)) - 1 reads only the shape of input_ids. Once FoldConstantCumsumPass folds it, nothing in the partition reads input_ids. When that input comes first, OpenVINO's PyTorch converter takes it for forward's self and removes it. The runtime still passes every partition input, so every call failed with "expected 2 args (inputs=1 + outputs=1), got 3". An unused input in any other position is kept by the converter. Not folding is no fix, because masks built from such a cumsum then go wrong on OpenVINO's CPU plugin from the second call on. Instead, when the converted model has exactly one parameter fewer than the partition has inputs, preprocess puts the first one back, so the compiled model takes the same inputs the delegate passes. The test leaves both the first input and a later one unused.

ExecuTorch can plan an output with a dynamic size while OpenVINO compiles a fixed shape for it, for example x[torch.ones(4, dtype=bool)] once OpenVINO folds the mask. The buffer the runtime makes for such an output started empty, and OpenVINO refuses an output tensor whose shape differs from a fixed one, so every call failed with 0x1. Before the owned buffers, these programs ran. The buffer now starts with the shape of the infer request's own output tensor: empty along each dynamic dimension and the full shape where OpenVINO fixed it.

FoldConstantCumsumPass evaluates a full_like from an empty tensor of its input's shape. That tensor went to the default device, so lowering for OpenVINO under torch.device("cuda") or set_default_device("cuda") failed on a CPU-only PyTorch with "Torch not compiled with CUDA enabled", and on a CUDA build it used the GPU for nothing. The pass evaluates everything else on the CPU already; this tensor now goes there too.

With inference_precision given twice, for example bf16 and then an empty value, lowering keeps the last entry and so compiles with the float32 default, but the runtime skipped empty entries and applied bf16. On x86, where the runtime decides, the program then computed in bfloat16. The runtime now takes the last entry as well, including an empty one, which means the default.

Lowering passes the precision too, so the comment was wrong to say only the runtime does. What makes the check depend on the runtime is that on x86 OpenVINO applies only the precision it gets when it loads the model.

The cumsum fold lines had landed between the comment and the decoder call it explains, so the comment read as if it were about the fold.

Since each cumsum is folded on its own, _evaluate is only ever asked for one node. Taking and returning that one value drops the list and dict it no longer needs, and a check that could never be false.

Only the attention mask test covered an int32 cumsum, and only through an OpenVINO CPU bug that newer OpenVINO releases fix. A fold limited to int64 now fails a pass-level test too.

Only x86 CPUs with bfloat16 units computed in bfloat16 before, so only they get slower, and only there does asking for bf16 bring the earlier speed back. On other x86 CPUs OpenVINO already computed in float32.

The precision docs said int64 results only go wrong outside the int32 range. Measured through the delegate on a CPU, an int64 sum is computed in float32: 16777216 + 1 gives 16777216, and 123456789 + 987654321 gives 1111111168. cumsum and prod near 2^24 stay exact.

Only an output compiled with a fully fixed shape refuses a buffer of another shape. A partly dynamic output accepts an empty one. Comment only.

OpenVINO 2025.1 has the same CPU plugin bug with integer cumsums over constants as the later releases, so the fold's docstring now starts the range there. Docstring only.

…ioner OpenVINO converts min, max, amin, amax, minimum, maximum, clamp and sign to its ReduceMin, ReduceMax, Minimum, Maximum and Sign operations, and none of those accept bool tensors. The partitioner still gave these ops to OpenVINO when they read bool tensors, so the whole program failed to lower: ReduceMin ... Element type of data input must be numeric. Got: boolean With PyTorch 2.15, MultivariateNormal exports two such mins when it checks scale_tril, so a model that builds one could not use OpenVINO. The partitioner now leaves these ops to the CPU when every tensor they read is bool, and the portable kernels compute them as PyTorch does. An op with a bool and a float input, such as maximum(mask, x), is computed in float, which OpenVINO converts, so it stays with OpenVINO. Other dtypes are not affected.

create_owned_output reported errors through its return value and its buffer through an out-parameter, and took a whole tensor only to read its dtype. It now returns exr::Result<ov_tensor_t*> and takes the dtype, like create_ov_tensor beside it, so its call site reads like the one for create_ov_tensor again. No behavior change.

…_precision The check that the runtime takes the last inference_precision entry ran only on x86 CPUs with bfloat16 units, so CI could skip it. A new test gives an invalid value and then an empty one. Lowering keeps only the empty one, and the runtime has to as well, or it fails to load the program. On the runtime before that fix it fails with "unsupported inference_precision 'f7'".

pytorch-bot · 2026-11-01T02:19:48Z

🔗 Helpful Links

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

📄 Preview Python docs built from this PR

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

❌ You can merge normally! (6 Unrelated Failures), 2 Unclassified Failures

As of commit b7623fe with merge base 05092c1 ():

UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:

Build macOS Wheels / pytorch/executorch / build-wheel-py3_11-cpu (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
Build macOS Wheels / pytorch/executorch / upload / upload-wheel-py3_11-cpu (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
Unable to download artifact(s): Artifact not found

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

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

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

Copilot

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

shoumikhin · 2026-11-01T03:22:28Z

@claude /pr-review

claude · 2026-11-01T03:23:17Z

Claude finished @shoumikhin's task in 22m 44s —— View job

PR Review: #24396. I found no blockers, only minor points: the CI script now skips the model tests after an op failure, preprocess has no sanity check, two tests can't catch what they target, and it's unclear whether all ten bool ops need to leave OpenVINO.

Detailed review

Summary

The PR keeps bool min/max/amin/amax/minimum/maximum/clamp/sign on the CPU. It also carries the #24294 follow-ups: re-adding a dropped first input, sizing OpenVINO-owned output buffers to the compiled shape, making the cumsum fold tensor on the CPU, taking the last inference_precision, failing the test runner, and docs. No blockers. All findings below are minor.

Code Quality

backends/openvino/preprocess.py:114-121: The fix-up assumes input 0 was dropped based only on the parameter count, and never checks the result.
- A count that is off in any other way still lowers. Every call then fails at the args check in OpenvinoBackend.cpp:475-482, which is the failure this PR fixes for one case.
- If a converter release ever dropped a different unused input, the new parameter would go to index 0 and shift the rest. The runtime binds inputs by index (OpenvinoBackend.cpp:513), so inputs with the same type and shape would silently swap.
- Fix: re-add the parameter only when the first placeholder of module.graph has no users, and raise if len(model.get_parameters()) != len(input_types) afterwards. Fix this →
backends/openvino/partitioner.py:36-41, 54 (low confidence: I did not check OpenVINO's support table or its clamp translator): aten.clamp.Tensor is not in bool_unsupported_ops, and _reads_only_bool assumes OpenVINO promotes mixed inputs. OpenVINO may instead claim clamp.Tensor and convert the bounds to the input's type (ConvertLike) before Maximum/Minimum. In that case torch.clamp(mask, min=float_tensor) would still hit the bool Maximum error, and so would clamp_min(mask, t) once it is decomposed. The fix would be to judge clamp by its first input only and add clamp.Tensor to the set.

Infrastructure

backends/openvino/tests/test_runner.py:75: .ci/scripts/test_openvino.sh runs under set -ex (line 8). With the new sys.exit(1), a failing op test ends the script before python test_runner.py --test_type models (line 16) starts. A failing CI run then reports nothing about the model tests, which used to run every time. Run both suites and exit non-zero at the end if either failed. Fix this →

Testing

backends/openvino/tests/ops/test_reductions.py:124-125: test_bool_ops_run_on_the_cpu returns only the .values of m.min(1) and m.max(1). The indices are the PR's reason for keeping these ops off OpenVINO, and rows 0 and 1 are all ties, but nothing compares the indices with eager. Moving the ops back into OpenVINO with a uint8 cast would not be caught. Return .indices too. Fix this →
backends/openvino/tests/ops/test_reductions.py:254: x is int64 in both subtests, so torch.cumsum(part, 0, dtype=torch.int32) + x is int64 whether the folded constant is int32 or int64. The new int32 subtest therefore can't catch a fold that drops dtype=. Give x the subtest's dtype so that assert_close also compares dtypes. Fix this →

API Design

backends/openvino/README.md:95-97 and docs/source/build-run-openvino.md:149-151 (low confidence: I did not check this against the OpenVINO source): the new sentence names only sum as computed in float32, which suggests the other integer reductions are exact. The CPU plugin's Reduce kernel may convert int32 values to float32 for every reduce mode. If so, amax, amin, max(), min() and prod round the same way above 2^24; for example, torch.tensor([16_777_217]).amax() would give 16,777,216. Please check amax and prod before the docs say only sum is affected.

Performance

backends/openvino/partitioner.py:51-62: The PR's reason for not casting inside OpenVINO is the unspecified tie order, but that only matters for the indices of min.dim/max.dim.
- The other eight ops have no indices and an exact bool form. amin/min are all, amax/max are any, minimum/maximum are and/or, sign is the identity, and clamp with a float bound can cast its input to float first.
- min.dim/max.dim don't need the CPU either when their indices are unused. The PR's own example reads only .values.
- Sending all ten to the CPU splits the OpenVINO partition wherever one of them sits mid-graph, which adds a delegate boundary and a portable-kernel round trip.
- A cast in preprocess would keep these ops in OpenVINO and leave only min.dim/max.dim with used indices on the CPU. _passes/cast_reduction_input_pass.py already does this for bool cumsum/prod.
- This is not a regression, since these graphs failed to lower before.
backends/openvino/partitioner.py:109-110 (medium confidence: traced by hand, not run): getitem is reported as supported even when its producer is not. Now that bool min.dim/max.dim are rejected, this appears to split the test model into two delegates:
- CapabilityBasedPartitioner's merge-all step puts the getitems of min.dim/max.dim into flip's partition.
- gt then can't join without a cycle through min.dim.
- The getitems are later moved back to their unpartitioned producers, leaving gt and flip as two delegates with a CPU round trip between them.
- That matches expected_partitions=2 at test_reductions.py:140, and the test now locks the split in.
- Reporting getitem as supported only when node.args[0] is should give one partition. The native backend already does this (backends/native/test/test_partitioner.py:99).
- The getitem rule predates this PR, but this PR's change is what triggers it. Fix this →

Recommendation

Approve. Nothing blocks merging, and none of the findings is a regression. The CI script change, the preprocess check and the two test fixes are small enough to make in this PR. The two partitioning points can be follow-ups.

· [Branch: openvino-bool-minmax](https://github.com/pytorch/executorch/tree/openvino-bool-minmax)

The OpenVINO CI job runs the op tests and then the model tests under set -e. Now that the test runner exits with code 1 when a test fails, a failing op test stopped the job before the model tests started, so a red run said nothing about the models. The script now runs both suites and exits with code 1 if either failed.

Preprocess put the first partition input back whenever the converted model had one parameter fewer than the partition has inputs. Now it does so only when that first input is really unused, and lowering fails when the counts still differ. The runtime binds inputs by position, so another mismatch would have made every call fail, or swapped two inputs of the same type and shape. A partition can also have no inputs at all, such as a comparison that reads only a buffer next to a bool min on the CPU, and a test covers that case.

TestBoolMinMax compared only the values of min(dim) and max(dim). Their indices are where the order of ties matters, and the all-true and all-false rows are all ties, so the test now compares the indices with eager too. Its docstring also says more exactly why these ops leave OpenVINO.

x was int64 in both subtests, so the result was int64 whatever dtype the folded cumsum had, and a fold that dropped dtype=torch.int32 still passed. x now has the subtest's dtype, so such a fold fails the int32 subtest.

The docs said only sum reduces integers in float32. Measured through the delegate on a CPU with OpenVINO 2026.4.1 and 2025.1.0, amax, amin, max and min of int32 and int64 tensors do too: amax over a tensor that holds 16,777,217 gives 16,777,216. Inputs and running totals round as well, so the sum of 16,777,217 and -16,777,216 gives 0. cumsum and maximum stay exact, and so does prod where OpenVINO computes it (2026.4.1).

The direct test of _match_partition_inputs gave both inputs the same shape and dtype and checked only how many parameters came back, so a version that appended the restored input, or built it from the second input, still passed. The runtime binds inputs by position, so either mistake would feed one input to the other's parameter. The test now gives the first input its own shape and dtype and checks both parameters in order. It needs no device, so it moves out of the op test class into its own unittest.TestCase.

An output that OpenVINO compiled with a dynamic rank cannot get a buffer, because an ExecuTorch tensor keeps its rank. No partition tried so far compiles to one, but if one does, the error now says so and names the fix: export with static sizes for the inputs that output depends on.

…ties The CPU precision notes listed where OpenVINO's results differ from eager PyTorch, but not the indices min(dim) and max(dim) return on ties: PyTorch returns the first one, and OpenVINO's CPU plugin can return a later one, for uint8 and other dtypes. Both pages now say so.

"The sum 16,777,216 + 1" read like element-wise add, which x86 computes exactly; the example is about the sum reduction. It now says sum over a tensor that holds both values.

Reading masked values after writing them, as in x[mask] = x[mask] * 2 return x + x[mask].sum() failed to lower with "Dynamic rank for aten::index input is not supported". OpenVINO converts index_put to a placeholder whose rank it takes from the decoder, and its FX decoder reads ranks only from each node's tensor_meta. ExecuTorch edge graphs leave tensor_meta empty and keep the shape in val. Preprocess now fills tensor_meta from val before conversion, the way other ExecuTorch passes do. OpenVINO releases that do not delegate index_put, such as 2025.1.0, skip the new test.

shoumikhin · 2026-11-01T21:10:23Z

I kept the failure because seven graphs built to get a dynamic-rank output all got a fixed rank, but the error now says to export with static sizes for the inputs that output depends on.

shoumikhin · 2026-11-01T21:10:24Z

@claude /pr-review

Copilot

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

claude · 2026-11-01T21:11:09Z

Claude finished @shoumikhin's task in 25m 31s —— View job

PR Review: #24396. I found no blockers and one minor docs point: the new tie note names uint8 but not float32, and the new notes on OpenVINO's CPU behavior don't say which release they describe.

Detailed review

Summary

The PR keeps bool min/max/amin/amax/minimum/maximum/clamp/sign on the CPU, fills tensor_meta so the masked read lowers, and carries the #24294 follow-ups. Nothing blocks merging, and the one finding below is minor.

I didn't repeat points you already deferred or decided in earlier rounds: how getitem is reported, casting bool inputs inside OpenVINO, and failing on an output compiled with a dynamic rank.
Nothing was run. The finding comes from reading the docs and the PR discussion.

API Design

backends/openvino/README.md:104-106 and docs/source/build-run-openvino.md:158-160: the tie note names uint8 but not float32.
- "This happens with uint8 and other dtypes" singles out uint8 because of the bool-to-uint8 cast discussed on this PR. Readers of the docs never see that discussion.
- The note comes right after the paragraph on integer precision. A reader with a float32 model, the common case, can take it as an integer-only quirk and expect the indices of min(dim) and max(dim) to match PyTorch. Your measurements found the later index for float32 as well as for uint8 and int32.
- Fix: name float32, for example "This happens with float32 as well as integer dtypes such as int32 and uint8."
- The same new text (README 95-106, docs 149-160) also doesn't say which OpenVINO release it describes.
  - The docs support openvino>=2025.1.0,<2027.0.0 (build-run-openvino.md:64). The PR description says the ARM list was measured with 2026.4.1.
  - _passes/fold_constant_cumsum_pass.py:111-112 already ties its bug to "2025.1 to 2026.4".
  - Naming the release would let readers tell when these plugin details have changed.
- Fix this →

Recommendation

Approve. Nothing blocks merging. The only finding is a small docs edit in the two mirrored files.

· [Branch: openvino-bool-minmax](https://github.com/pytorch/executorch/tree/openvino-bool-minmax)

The lint job runs mypy without OpenVINO installed, so the op_support import that the new index_put test needs failed with import-not-found. The file now turns that check off, as test_reductions.py does for the same import.

The new notes on the CPU plugin did not say which OpenVINO release they describe, and the tie note named uint8 but not float32, so a reader with a float32 model could take it for an integer-only quirk. Both notes now name OpenVINO 2026.4.1, the release they were measured with, and the tie note names float32 as well as int32 and uint8.

shoumikhin · 2026-11-01T22:23:20Z

@claude /pr-review

Copilot

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

claude · 2026-11-01T22:24:08Z

Claude finished @shoumikhin's task in 42m 52s —— View job

PR Review: #24396. I found no blockers and two minor points, neither a regression. First, preprocess still fails to lower when OpenVINO drops a first input that only ones_like reads. Second, an owned output can start smaller than the minimum size OpenVINO compiled for it.

Detailed review

Summary

The PR keeps bool min/max/amin/amax/minimum/maximum/clamp/sign on ExecuTorch's CPU kernels, fills tensor_meta so the masked read lowers, and carries the #24294 follow-ups. Nothing blocks merging. Both findings below are minor, and the models they describe already failed before this PR.

I didn't repeat points you deferred or decided in earlier rounds: how getitem is reported, casting bool inputs inside OpenVINO, and failing on an output with a dynamic rank.
Nothing was run. Python is blocked in this job and the OpenVINO source isn't available, so both findings come from reading the code plus OpenVINO behavior I remember but could not check.

Code Quality

backends/openvino/preprocess.py:50 (medium confidence: _reads_only_shape says OpenVINO folds such a full_like, but I am going from memory that it folds before the converter drops an unused parameter 0): the first input is put back only when its placeholder has no FX users. The converter, though, drops parameter 0 when nothing reads it in the converted model. An earlier review round suggested this FX check, and it turns out to be narrower than the converter's rule.
- The two rules disagree when the first input feeds only a full_like with a static shape. _reads_only_shape (_passes/fold_constant_cumsum_pass.py:17-21) says OpenVINO folds that full_like into a constant. That leaves the input with no reader, so the converter drops it as self.
- Trigger: forward(x, y): return torch.ones_like(x) + y with static shapes, which is the test at tests/ops/test_reductions.py:101 without the cumsums. FX still shows full_like reading x, so lowering fails with "expected 2 parameters in the converted model, got 1".
- Before this PR such a model failed on every call. It is the same OpenVINO behavior the PR fixes for the cumsum fold, reached another way.
- Fix: put the input back when all(_reads_only_shape(u) for u in placeholders[0].users), which is also true when there are no users. Keep the count check, so that TestMatchPartitionInputs still covers x + y, and add the test above.
- Fix this →
backends/openvino/runtime/OpenvinoBackend.cpp:712 (low confidence: I recall that the CPU plugin's set_tensor refuses a buffer whose shape is not compatible with the output's partial shape, but I could not read it, and no test here has such an output): a dynamic dimension that OpenVINO compiled with a lower bound above 0 starts at 0, which is outside its range.
- Preprocess passes every symbolic size to OpenVINO as -1 (preprocess.py:116). A lower bound appears when the partition adds a fixed size to a dynamic one, for example torch.cat of a fixed tensor and a dynamic one, or F.pad along a dynamic dimension.
- Trigger: torch.cat([torch.zeros(1, 8), x]) with dim 0 of x dynamic. OpenVINO compiles dim 0 of the output with a lower bound of 1, but the owned buffer starts at [0, 8]. infer_request_set_output_tensor_by_index would then fail on every call.
- The removed all-zero code had the same gap. Still, this is the line the PR changes so that the buffer starts from the compiled shape.
- Fix: dims[d] = std::max<int64_t>(dim.min, 0); handles fixed, bounded and unbounded dimensions in one expression. Update the comment at 706-708 to match.
- Fix this →

Recommendation

Approve. Nothing blocks merging. Each fix is a one-line change plus a test, and neither model ran before this PR.

· [Branch: openvino-bool-minmax](https://github.com/pytorch/executorch/tree/openvino-bool-minmax)

shoumikhin · 2026-11-02T16:52:03Z

@pytorchbot cherry-pick --onto release/1.6 -c critical

pytorchbot · 2026-11-02T16:55:55Z

Cherry picking #24396

Command git -C /home/runner/work/executorch/executorch cherry-pick -x -X theirs efbd460b0a675b97fbd4be989c07d10347c3d9b4 returned non-zero exit code 1

Auto-merging backends/openvino/README.md
CONFLICT (modify/delete): backends/openvino/_passes/fold_constant_cumsum_pass.py deleted in HEAD and modified in efbd460b0a (OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)).  Version efbd460b0a (OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)) of backends/openvino/_passes/fold_constant_cumsum_pass.py left in tree.
Auto-merging backends/openvino/preprocess.py
Auto-merging backends/openvino/runtime/OpenvinoApi.h
Auto-merging backends/openvino/runtime/OpenvinoBackend.cpp
Auto-merging backends/openvino/runtime/OpenvinoBackend.h
Auto-merging backends/openvino/tests/ops/test_addmm.py
CONFLICT (modify/delete): backends/openvino/tests/ops/test_index_put.py deleted in HEAD and modified in efbd460b0a (OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)).  Version efbd460b0a (OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)) of backends/openvino/tests/ops/test_index_put.py left in tree.
CONFLICT (modify/delete): backends/openvino/tests/ops/test_reductions.py deleted in HEAD and modified in efbd460b0a (OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)).  Version efbd460b0a (OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)) of backends/openvino/tests/ops/test_reductions.py left in tree.
Auto-merging backends/openvino/tests/ops/test_view.py
Auto-merging docs/source/build-run-openvino.md
error: could not apply efbd460b0a... OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 (#24396)
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".
hint: Disable this message with "git config set advice.mergeConflict false"

Details for Dev Infra team

Raised by workflow job

shoumikhin · 2026-11-02T16:57:39Z

@pytorchbot cherry-pick --onto cherry-pick-24294-by-pytorch_bot_bot_ -c critical

pytorchbot · 2026-11-02T17:01:42Z

Cherry picking #24396

The cherry pick PR is at #24446 and it is recommended to link a critical cherry pick PR with an issue.

Details for Dev Infra team

Raised by workflow job

…ductions (#24492) Supersedes #24377 with a clean release pick from #24294. Fixes scalar tensors, float32 CPU defaults, dynamic output buffers and integer reductions. Includes the related #24396 runtime, folded-cumsum, parameter-count and CI runner follow-ups previously spread across #24377 and #24446. This pick contains the complete core OpenVINO fix and its required follow-ups. Bool-op handling and masked-read metadata are isolated in the next clean pick. The source float32 default can cost speed on CPUs with bfloat16 hardware; inference_precision=bf16 remains available. ## Scope and landing order Land after #24491 in the verified landing order. The OpenVINO pair follows the CUDA picks; these backend groups can otherwise be reviewed separately. This branch starts directly at release/1.6 commit `dfb78b9ecd933a5fee33ebc94f69ed4b71cbb1e7`. Its GitHub diff contains 16 files for this pick; it does not carry duplicate #24298 history or the excluded unmerged QNN work. Dependencies are documented here rather than embedded as other cherry-pick commits. ## Verification All changed Python files compile and pass Ruff F821 checks. All seven replacements merge cleanly in the documented sequence, including simulated squash merges. No QNN files are changed. The combined OpenVINO production code matches the previously reviewed final #24446 code; the bool test class is preserved unchanged. Native CUDA, OpenVINO and portable C++ suites were not run locally on this macOS host; PR CI remains required before landing. Prepared with OpenAI Codex.

Supersedes #24446 with a clean release pick from #24396. Keeps unsupported bool-only min/max/clamp/sign operations on the CPU and populates tensor metadata for masked-read lowering. Includes their regression tests. The bool test class is moved unchanged to test_bool_min_max.py so this PR can be based directly on release/1.6 without carrying the core OpenVINO commit. ## Scope and landing order Land after #24492 in the verified landing order. This branch starts directly at release/1.6 commit `dfb78b9ecd933a5fee33ebc94f69ed4b71cbb1e7`. Its GitHub diff contains 4 files for this pick; it does not carry duplicate #24298 history or the excluded unmerged QNN work. Dependencies are documented here rather than embedded as other cherry-pick commits. ## Verification All changed Python files compile and pass Ruff F821 checks. All seven replacements merge cleanly in the documented sequence, including simulated squash merges. No QNN files are changed. The combined OpenVINO production code matches the previously reviewed final #24446 code; the bool test class is preserved unchanged. Native CUDA, OpenVINO and portable C++ suites were not run locally on this macOS host; PR CI remains required before landing. Prepared with OpenAI Codex.

shoumikhin and others added 16 commits October 31, 2026 14:39

Say why the OpenVINO bf16 addmm check needs the runtime

abc9129

Lowering passes the precision too, so the comment was wrong to say only the runtime does. What makes the check depend on the runtime is that on x86 OpenVINO applies only the precision it gets when it loads the model.

Keep the OpenVINO input types comment above the converter call

ec69164

The cumsum fold lines had landed between the comment and the decoder call it explains, so the comment read as if it were about the fold.

Evaluate one node at a time in the OpenVINO cumsum fold

94475c1

Since each cumsum is folded on its own, _evaluate is only ever asked for one node. Taking and returning that one value drops the list and dict it no longer needs, and a check that could never be false.

Test the OpenVINO cumsum fold on an int32 cumsum

3c3a02e

Only the attention mask test covered an int32 cumsum, and only through an OpenVINO CPU bug that newer OpenVINO releases fix. A fold limited to int64 now fails a pass-level test too.

Say which x86 CPUs the OpenVINO float32 default slows down

9bd7aa6

Only x86 CPUs with bfloat16 units computed in bfloat16 before, so only they get slower, and only there does asking for bf16 bring the earlier speed back. On other x86 CPUs OpenVINO already computed in float32.

Say which OpenVINO outputs refuse an empty buffer

74383d7

Only an output compiled with a fully fixed shape refuses a buffer of another shape. A partly dynamic output accepts an empty one. Comment only.

Say the OpenVINO cumsum fold is needed from 2025.1

8cf22fd

OpenVINO 2025.1 has the same CPU plugin bug with integer cumsums over constants as the later releases, so the fold's docstring now starts the range there. Docstring only.

shoumikhin added the release notes: openvino OpenVino backend related issues, features, bugs etc. label Nov 1, 2026

shoumikhin requested a review from mergennachin as a code owner November 1, 2026 02:19

Copilot AI balanced review requested due to automatic review settings November 1, 2026 02:19

meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Nov 1, 2026

Copilot AI reviewed Nov 1, 2026

shoumikhin added 2 commits October 31, 2026 21:39

shoumikhin mentioned this pull request Nov 1, 2026

Fix 0-d tensors, dynamic output sizes and integer reductions, and default to float32 on CPU, in the OpenVINO backend #24377

Closed

shoumikhin added 3 commits October 31, 2026 21:56

Check the dtype of a folded int32 cumsum in the OpenVINO test

154350d

x was int64 in both subtests, so the result was int64 whatever dtype the folded cumsum had, and a fold that dropped dtype=torch.int32 still passed. x now has the subtest's dtype, so such a fold fails the int32 subtest.

shoumikhin added 5 commits November 1, 2026 12:04

Make the OpenVINO float32 sum example read as a reduction

1e784ca

"The sum 16,777,216 + 1" read like element-wise add, which x86 computes exactly; the example is about the sum reduction. It now says sum over a tensor that holds both values.

Copilot AI balanced review requested due to automatic review settings November 1, 2026 21:10

shoumikhin changed the title ~~OpenVINO: fix bool min/max lowering and follow-ups to #24294~~ OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 Nov 1, 2026

Copilot AI reviewed Nov 1, 2026

shoumikhin added 2 commits November 1, 2026 13:21

Let mypy check the OpenVINO index_put test without OpenVINO

b964db8

The lint job runs mypy without OpenVINO installed, so the op_support import that the new index_put test needs failed with import-not-found. The file now turns that check off, as test_reductions.py does for the same import.

Copilot AI balanced review requested due to automatic review settings November 1, 2026 22:23

Copilot AI reviewed Nov 1, 2026

SS-JIA approved these changes Nov 2, 2026

View reviewed changes

shoumikhin merged commit efbd460 into pytorch:main Nov 2, 2026
551 of 562 checks passed

This was referenced Nov 2, 2026

[v1.6.0] Release Schedule and Tracker #23608

Open

OpenVINO: fix bool min/max and masked read lowering, and follow-ups to #24294 #24446

Closed

OpenVINO: LeRobot policies that do not run yet, and what blocks them #24325

Open

This was referenced Nov 3, 2026

[release/1.6] Fix OpenVINO scalars, precision, dynamic outputs and reductions #24492

Merged

[release/1.6] Fix OpenVINO bool operations and masked reads #24493

Merged

Conversation

shoumikhin commented Nov 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is wrong today

What this change does

What was tested

Uh oh!

pytorch-bot Bot commented Nov 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Helpful Links

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

❌ You can merge normally! (6 Unrelated Failures), 2 Unclassified Failures

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

shoumikhin commented Nov 1, 2026

Uh oh!

claude Bot commented Nov 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Code Quality

Infrastructure

Testing

API Design

Performance

Recommendation

Uh oh!

shoumikhin commented Nov 1, 2026

Uh oh!

shoumikhin commented Nov 1, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

claude Bot commented Nov 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

API Design

Recommendation

Uh oh!

shoumikhin commented Nov 1, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

claude Bot commented Nov 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Code Quality

Recommendation

Uh oh!

Uh oh!

shoumikhin commented Nov 2, 2026

Uh oh!

pytorchbot commented Nov 2, 2026

Cherry picking #24396

Uh oh!

shoumikhin commented Nov 2, 2026

Uh oh!

pytorchbot commented Nov 2, 2026

Cherry picking #24396

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

shoumikhin commented Nov 1, 2026 •

edited

Loading

pytorch-bot Bot commented Nov 1, 2026 •

edited

Loading

claude Bot commented Nov 1, 2026 •

edited

Loading

claude Bot commented Nov 1, 2026 •

edited

Loading

claude Bot commented Nov 1, 2026 •

edited

Loading