XNNPACK: fix enable_bf16 load failures and BatchNorm folding into a 3-D linear output by shoumikhin · Pull Request #24464 · pytorch/executorch

shoumikhin · 2026-11-02T20:42:40Z

What is wrong today

XnnpackPartitioner(enable_bf16=True) lets XNNPACK run bf16 nodes. Without it, bf16 matrix multiplies run on the single-threaded portable kernels, which is very slow. With it, a program can fail to load:

The partitioner hands XNNPACK bf16 nodes that XNNPACK cannot define in bf16: softmax, mean, average and max pooling, bilinear upsampling, and batch norm that does not fold into a linear. Loading fails with xnn_status_invalid_parameter.
Batch matrix multiply (bmm) is defined with a bf16 output, but XNNPACK only multiplies bf16 matrices into an fp32 result. Loading fails with Failed to create BMM node.

A bf16 attention block written with matmul and softmax hits both.

What this change does

A config can now say it does not support bf16 (supports_bf16 = False), so its bf16 nodes stay on the portable kernels and the partitioner logs why. Softmax, mean, both poolings, bilinear upsampling and convolution set it. The default is True: XNNPACK rewrites most bf16 ops to fp32 internally, and at the pinned commit only these reject bf16 when defined. A bf16 run of the other float ops found no other failure.
A bf16 batch norm is kept in XNNPACK only when FuseBatchNormPass.can_fuse says it folds into the linear before it.
can_fuse now also requires the batch norm to be the only user of the linear output, and the linear output to be 2-D. Without these checks, a bf16 batch norm could be kept but left unfused, so loading failed, and a batch norm after a 3-D linear output was folded along the wrong dim, which gave wrong results in fp32 and bf16.
A bf16 bmm now writes an fp32 result and converts it to bf16, as the linear layer already did.

With this change, the SmolVLA robot policy (a vision-language-action model) in bf16 with enable_bf16=True loads, and then runs one action chunk in about 11 seconds on 16 x86 cores, instead of about 9 minutes with the default partitioner.

Tests

test_enable_bf16_leaves_ops_xnnpack_cannot_define_in_bf16: each op, and a convolution followed by a batch norm, is delegated in fp32 but not in bf16, and the bf16 program matches eager.
test_enable_bf16_fuses_batch_norm_into_a_linear: a bf16 linear followed by BatchNorm1d runs fully in XNNPACK. When the linear output is also used elsewhere, the batch norm stays out.
test_enable_bf16_runs_an_attention_block: the linear layers and both bmms run in XNNPACK, the softmax stays outside.
test_bf16_bmm in test_bmm.py, and test_fp32_linear_batch_norm_on_3d_output in test_batch_norm_fusion.py.

All of these fail before this change, except the fused batch norm case, which guards the fusion that already worked. Ran the XNNPACK partitioner, op and pass tests on Linux x86_64. The only failures, in the per-channel int4 linear tests, also happen without this change.

pytorch-bot · 2026-11-02T20:42:45Z

🔗 Helpful Links

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

📄 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

⏳ No Failures, 13 Pending

As of commit fdbbcb5 with merge base 893d815 ():
💚 Looks good so far! There are no failures yet. 💚

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-02T20:42:58Z

@claude /pr-review

claude · 2026-11-02T20:43:40Z

Claude finished @shoumikhin's task in 18m 21s —— View job

PR Review: #24464

Summary: supports_bf16 defaults to True, so with enable_bf16 any op that XNNPACK can't define in bf16 and that isn't on the new seven-config list still fails at load; that default should be settled before merge, and the other four findings are minor.

Detailed review

Summary

This PR adds a per-config supports_bf16 flag so that enable_bf16 stops delegating seven ops XNNPACK can't define in bf16. It also makes bf16 bmm write an fp32 result and convert it to bf16, as linear already did. The main issue is the flag's opt-out default. The other findings:

a lost diagnostic message
a helper parameter whose name means different ids in the two helpers
no op-level bf16 bmm test
a small fusion regression for bf16 Linear → BatchNorm

All six changed files were reviewed. Nothing was run, and the XNNPACK submodule isn't checked out here, so I couldn't check which other ops XNNPACK refuses in bf16.

Code Quality

bf16 rejections now only log "invalid dtype". The PR removes why(node, "XNNPACK does not support BF16 convolution") from ConvolutionConfig.check_constraints (it sat after gemm_configs.py:364). Every config with supports_bf16 = False now fails in check_common_constraints with the generic reason "invalid dtype" (xnnpack_config.py:176-179). So a user who passed enable_bf16=True and reads the WhyNoPartition log for a bf16 conv, softmax or pooling node is told that the dtype they just enabled is invalid. When self.enable_bf16 and not self.supports_bf16 and the node has a bf16 tensor, log a reason that names the op. Fix this →
output_id means a different id in each new helper. In defineBf16MatMulResult, output_id is the serialized id and remapped_output_id is the remapped one (XNNCompiler.cpp:833-834). In convertBf16MatMulResult, output_id is the remapped id (:873), and the only thing that decides whether a convert is emitted is result_id == output_id (:875). A future caller that passes the serialized id, as the first helper's naming suggests, would define a convert between unrelated values for every non-bf16 node. Rename the second helper's parameter to remapped_output_id. Fix this →

Testing

The new bf16 bmm runtime path has no op-level test. test/ops/test_bmm.py has only test_fp16_bmm and test_fp32_bmm, and _test_bmm always lowers with the default partitioner. The fp32-result-then-convert path in defineBatchMatrixMultiplyNode runs only inside test_enable_bf16_runs_an_attention_block, in a model that also has linear, transpose, mul and softmax. A regression there would show up as a mismatch in the whole model rather than in bmm. Add test_bf16_bmm using XnnpackPartitioner(enable_bf16=True) and bf16 tolerances, the way test_linear.py:732-747 handles bf16. Fix this →

API Design

supports_bf16 defaults to True, which makes the fix a deny-list (xnnpack_config.py:51, applied at :277). Every config claims bf16 support unless it opts out, and only the seven configs in this PR opt out. With enable_bf16=True, any other op XNNPACK refuses in bf16 still fails at load with the same xnn_status_invalid_parameter this PR fixes. The same goes for any config added later.
- A missing entry in this list means the program fails to load. A missing entry in an opt-in list would only leave that op on the portable kernels, and the program would still load.
- The comment at :60-63 already says XNNPACK's bf16 coverage is narrow.
- Consider defaulting to False and opting in the configs known to load in bf16: linear, addmm, mm, bmm, and the elementwise and data-movement ops that the attention test and SmolVLA use. Otherwise, explain why opt-out is preferred.
- I couldn't check which other ops actually fail, because the XNNPACK sources aren't in this checkout.

Performance

bf16 Linear → BatchNorm no longer fuses inside the delegate. BatchNormConfig.supports_bf16 = False (node_configs.py:28) rejects every bf16 batch norm, including ones that never become a conv.
- FuseBatchNormPass.can_fuse also accepts a preceding linear (fuse_batch_norm.py:95-98). It folds the batch norm in with fuse_linear_bn_weights (:227), which leaves a plain bf16 fully-connected, and this PR's runtime path supports that.
- Only batch norm after a conv, or a standalone batch norm (decomposed into a 1x1 depthwise conv), turns into a bf16 conv.
- Before this PR, a bf16 nn.Linear(8, 8) followed by nn.BatchNorm1d(8) with enable_bf16=True was folded into the delegate. Now the batch norm runs on the portable kernels and splits the graph.
- Fix: remove the flag from BatchNormConfig (so it uses the default), and in check_constraints reject bf16 unless input_node is a linear that can_fuse accepts.
- This comes from reading the code; I didn't run it. Fix this →

Recommendation

Needs Discussion

I found no bug in the changed code. The open question is whether supports_bf16 should be opt-in. The other findings are minor and could land as follow-ups.

JakeStevens

Runtime bmm fix looks right to me. Main asks are narrowing the BatchNorm opt-out so bf16 Linear -> BatchNorm1d fusion keeps working, and adding an fp32 positive control to the excluded-ops test. The fp32-wrap idea for softmax/mean/pool/resize is fine as a follow-up.

Review drafted with Claude Code.

JakeStevens · 2026-11-02T20:59:53Z


 class BatchNormConfig(XNNPartitionerConfig):
    target_name = "_native_batch_norm_legit_no_training.default"
+    supports_bf16 = False


I think this is broader than it needs to be. check_constraints accepts BN either when it can be decomposed to a depthwise conv (which XNNPACK rejects in bf16) or when FuseBatchNormPass.can_fuse can fold it into a preceding linear. The fold path ends up as a bf16 FC, which already works. With the class-level flag, a bf16 Linear -> BatchNorm1d that fuses into XNNPACK today would now leave the BN on portable. Could we reject bf16 in check_constraints only when it can't fuse into a linear?

Good point, thanks. A bf16 BatchNorm that folds into a linear is delegated again. BatchNormConfig refuses a bf16 BatchNorm only when it would not fold into a linear, because then it becomes a depthwise convolution or folds into a convolution, and XNNPACK cannot define either in bf16. While testing this I found 2 gaps in FuseBatchNormPass.can_fuse, which this check relies on. It did not check that the BatchNorm is the only user of the linear output, which the pass requires, so a bf16 BatchNorm after such a linear stayed unfused and failed to load. It also accepted a 3-D linear output, where BatchNorm normalizes a different dim, so the folded linear gave wrong results, in fp32 too. can_fuse now checks both; the 3-D fix is its own commit, with a test in test_batch_norm_fusion.py. test_enable_bf16_fuses_batch_norm_into_a_linear covers both cases: a bf16 Linear followed by BatchNorm1d runs entirely in XNNPACK, and when the linear output is also used elsewhere, the BatchNorm stays out. Both match eager. The refusal test also has a Conv2d followed by BatchNorm2d, which has to stay out.

One case fails to load, as it does on main: with per_op_mode=True the BatchNorm gets its own delegate, so it cannot fold into the linear. The first version of this PR avoided that by refusing every bf16 BatchNorm, which also blocked the fusion.

JakeStevens · 2026-11-02T20:59:53Z


 class SoftmaxConfig(GenericNodePartitionerConfig):
    target_name = "_softmax.default"
+    supports_bf16 = False


In the pinned XNNPACK, softmax, mean, pooling and resize fail only at define time (e.g. subgraph/softmax.c:165). xnn_subgraph_fallback_from_bf16_to_fp32 would otherwise rewrite them to fp32 with converts. GetOpActionBf16 returns kRewrite for them, and also for FC and BMM, so linear and bmm already run as fp32 GEMMs. Did you consider defining these ops in fp32 in XNNCompiler with converts around them, like you do for bmm here? That would keep a bf16 attention block in one delegate instead of running softmax on single-threaded portable between two partitions. Happy for that to be a follow-up, but if we keep the flags, it'd help to note that they're tied to the XNNPACK pin.

Agreed, that is a good follow-up. It would keep softmax in XNNPACK instead of on the single-threaded portable kernel. It would not put this block into 1 delegate, though: the expand copies from the 3-D matmul split it into 3 delegates in fp32 too. I left it for a follow-up, as you suggested. The comment on supports_bf16 now ties the flags to the pinned XNNPACK commit.

JakeStevens · 2026-11-02T20:59:53Z

+    # XNNPACK defines some ops only for fp32 and fp16 tensors. Their configs set this
+    # to False, so enable_bf16 leaves their bf16 nodes to the portable kernels
+    # instead of handing XNNPACK a node it refuses when the program loads.
+    supports_bf16 = True


Nit: since this is opt-out, a new config whose XNNPACK define rejects bf16 will still be partitioned and fail only at load. A test that walks ALL_PARTITIONER_CONFIGS with bf16 inputs would catch that. Also, the conv-specific why() message is gone. A why() when bf16 is rejected because supports_bf16 is False would keep that diagnostic for all of these ops.

Added the why(): a config with supports_bf16 = False now logs "XNNPACK does not support bf16 for this op" when it refuses a bf16 node.

I kept the default at True because XNNPACK runs most ops in bf16 by rewriting them to fp32, and only a few ops reject bf16 at define time. I ran the other float ops with bf16 inputs, and they all load and match eager. With opt-in, about 45 configs would need a line, and any one we missed would quietly move that op to the portable kernels for people who use bf16 today. A walk over ALL_PARTITIONER_CONFIGS needs a sample graph for each config. I think it fits best with the fp32 follow-up, which needs a bf16 run per op anyway.

JakeStevens · 2026-11-02T20:59:53Z

+                    export(module, (x,)),
+                    partitioner=[XnnpackPartitioner(enable_bf16=True)],
+                )
+                self.assertFalse(


This checks that nothing is delegated, but it would also pass if the module were rejected for an unrelated reason (a mean dims constraint, a BN decompose precondition, etc.). Could you lower the same module in fp32 and assert that it is delegated, so the test shows supports_bf16 is what excludes it? A bf16 Linear -> BatchNorm1d case would also cover the fusion path from the BatchNormConfig comment.

Done. Each module is now lowered in fp32 first and must be delegated, so the test shows that bf16 is what keeps it out. The Linear followed by BatchNorm1d case is in test_enable_bf16_fuses_batch_norm_into_a_linear.

JakeStevens · 2026-11-02T20:59:53Z

+            "aten.linear.default",
+            "aten.mm.default",
+        }
+        self.assertEqual(left_on_cpu & matmuls, set())


Nit: asserting the number of delegates (or that softmax stays outside) would record the current split, so we notice if the partitioning changes. Separately, the existing bf16 coverage lives in the per-op Tester tests (test_linear.py, test_conv2d.py). A bf16 case in test_bmm.py would fit that pattern.

Done, both. The test now expects 3 delegates and checks that the softmax stays outside. The expand copies that the 3-D matmul turns into are what split the block, in fp32 as well. I also added test_bf16_bmm to test_bmm.py, in the same style as the bf16 conv tests.

…upport XnnpackPartitioner(enable_bf16=True) lets XNNPACK run bf16 nodes, so bf16 linear layers stop running on the single-threaded portable kernels. But a program lowered this way can fail when it loads: 1. The partitioner hands XNNPACK bf16 nodes that XNNPACK cannot define in bf16: softmax, mean, average pooling, max pooling, bilinear upsampling and batch norm. 2. Batch matrix multiply is defined with a bf16 output, but XNNPACK only multiplies bf16 matrices into an fp32 result. A partitioner config can now say it does not support bf16 (supports_bf16 = False), and enable_bf16 adds bf16 only for the configs that support it. The configs of the ops above set it, and convolution moves its own bf16 check to the same flag. At runtime a bf16 batch matrix multiply writes an fp32 result and converts it to the bf16 output, the pattern the linear layer already used, now shared by both ops.

…6 tests A bf16 BatchNorm that follows a linear folds into the linear's weights, and the result is a bf16 fully-connected, which XNNPACK runs. BatchNormConfig now keeps a bf16 BatchNorm when FuseBatchNormPass.can_fuse accepts the linear before it, instead of refusing every bf16 BatchNorm. With per_op_mode the BatchNorm still gets its own delegate, so it cannot fold and the program fails to load, as it does without this change. FuseBatchNormPass.can_fuse now also checks that the BatchNorm is the only user of its input, as the pass itself requires before it fuses. Before, can_fuse accepted a linear whose output had other users, so the partitioner kept a bf16 BatchNorm that the pass then left unfused, and the program failed to load. A config that sets supports_bf16 = False now logs why it refuses a bf16 node, as the convolution config did before, and the comment notes that the list follows the pinned XNNPACK commit. convertBf16MatMulResult() now names its output parameter remapped_output_id, since it takes the remapped id. Tests: - test_enable_bf16_leaves_ops_xnnpack_cannot_define_in_bf16 also lowers each module in fp32 and checks that it is delegated, so the test shows that bf16 is what keeps it out. It adds a convolution followed by a BatchNorm, which must stay out too. - test_enable_bf16_fuses_batch_norm_into_a_linear checks that a bf16 linear followed by BatchNorm1d runs entirely in XNNPACK, and that the BatchNorm stays out when the linear output is also used elsewhere. - test_enable_bf16_runs_an_attention_block records the number of delegates and checks that the softmax stays out. - test_bmm.py gets a bf16 case, like the bf16 cases in the other op tests.

…s 2-D BatchNorm normalizes dim 1. For a 2-D linear output, dim 1 holds the linear's output features, so FuseBatchNormPass can fold the BatchNorm into the linear's weights. For a 3-D output it does not. can_fuse still accepted that case, so when the sizes happened to match, the folded linear gave wrong results without any error, in fp32 and in bf16. When the sizes did not match, lowering failed inside the pass. can_fuse now accepts a linear only when its output is 2-D. Otherwise the BatchNorm is decomposed into a depthwise convolution, which normalizes dim 1, or in bf16 it stays on the portable kernels. Test: test_fp32_linear_batch_norm_on_3d_output lowers a Linear followed by BatchNorm1d on a 3-D input to XNNPACK, checks that the BatchNorm runs inside the delegate, runs the program and compares with eager. Without this change the outputs do not match.

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-02T22:56:03Z

@claude /pr-review

claude · 2026-11-02T22:57:01Z

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

PR Review: #24464

Summary: Two minor issues are left in the BatchNorm path, and neither blocks merging: with force_non_static_weights_for_f32_linear=True a bf16 BatchNorm after a linear still fails to load, and the new can_fuse reasons never reach the log.

Detailed review

Summary

This PR keeps bf16 nodes that XNNPACK can't define in bf16 out of the delegate. It keeps a bf16 BatchNorm only when it folds into a linear, and it makes a bf16 bmm write an fp32 result that is then converted to bf16. Two minor problems are left, both in the BatchNorm path.

All 9 changed files were reviewed. No tests were run, because running Python isn't permitted in this job. The XNNPACK submodule isn't checked out, so the list of ops XNNPACK rejects in bf16 comes from the PR and the discussion, not from the XNNPACK sources.

Code Quality

A bf16 BatchNorm after a linear still fails to load with force_non_static_weights_for_f32_linear=True (node_configs.py:46-48).
- BatchNormConfig calls can_fuse on the full program at partition time. The fold happens later, in preprocess, on the delegate's own program, and it can fail there. The discussion already names per_op_mode as one such case. This flag is a second one, and unlike per_op_mode, the config can see it: every config has self.force_non_static_weights_for_f32_linear (xnnpack_config.py:64).
- Trigger: XnnpackPartitioner(enable_bf16=True, force_non_static_weights_for_f32_linear=True) on a bf16 Linear(8, 4) followed by BatchNorm1d(4), with a 2-D input.
  - _detect_precision labels every weight without a dequant as FP32, including bf16 (gemm_configs.py:91-92). So LinearConfig leaves the weight and bias out of the partition (gemm_configs.py:237-243, :318-324), and they reach the delegate as inputs.
  - In preprocess, can_fuse then fails its is_param_node check (fuse_batch_norm.py:132-137). DecomposeBatchNorm runs next (_passes/__init__.py:86-87) and turns the BatchNorm into a depthwise convolution. The PR's own premise is that XNNPACK can't define that in bf16, so loading fails with xnn_status_invalid_parameter.
- The same thing happens on main, so this is a gap in the fix, not a regression. fp32 is unaffected, because an fp32 depthwise convolution loads.
- Fix: also require not self.force_non_static_weights_for_f32_linear in the linear condition. Add a subtest with that flag to test_enable_bf16_fuses_batch_norm_into_a_linear that expects the BatchNorm outside the delegate.
- I found this by reading the code and did not run it. Fix this →
The two new can_fuse reasons are never logged (fuse_batch_norm.py:107-108, :153-154).
- No caller passes why to can_fuse (node_configs.py:38, fuse_batch_norm.py:57). When a bf16 BatchNorm follows a linear whose output is 3-D or has another user, the only log line is "XNNPACK supports a bf16 BatchNorm only when it fuses into a linear", which doesn't say what stopped the fold.
- Passing why alone would raise, because can_fuse now uses two calling styles. The new calls are why(bn, reason), but the five older calls (:100, :118, :129, :136, :148) pass only a reason. WhyNoPartition.__call__(self, node, reason) (exir/backend/utils.py:575) needs both arguments, so those calls would raise TypeError.
- Fix: change the five older calls to why(bn, ...) and pass why at node_configs.py:38. Fix this →

Recommendation

Approve

Nothing blocks merging. Each fix is a few lines and could go in this PR.

shoumikhin · 2026-11-02T23:29:51Z

Thanks. Both are real but not new on main, so I will handle them in follow-ups. With force_non_static_weights_for_f32_linear a bf16 linear already fails to load on its own, so the BatchNorm check is not what blocks that graph. Logging the can_fuse reasons needs the older why calls fixed first, and it should log only when the fold decides the refusal.

shoumikhin · 2026-11-03T00:15:14Z

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

shoumikhin · 2026-11-03T00:15:15Z

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

pytorchbot · 2026-11-03T00:18:46Z

Cherry picking #24464

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

Details for Dev Infra team

Raised by workflow job

shoumikhin · 2026-11-03T00:56:52Z

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

pytorchbot · 2026-11-03T01:00:20Z

Cherry picking #24464

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

Details for Dev Infra team

Raised by workflow job

Copilot AI balanced review requested due to automatic review settings November 2, 2026 20:42

shoumikhin added the release notes: xnnpack Changes to the XNNPack backend delegate label Nov 2, 2026

shoumikhin requested a review from digantdesai as a code owner November 2, 2026 20:42

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 2, 2026

Copilot AI reviewed Nov 2, 2026

JakeStevens self-requested a review November 2, 2026 20:45

JakeStevens requested changes Nov 2, 2026

View reviewed changes

shoumikhin added 3 commits November 2, 2026 14:37

shoumikhin force-pushed the xnnpack-bf16-ops branch from bc82c53 to fdbbcb5 Compare November 2, 2026 22:55

Copilot AI balanced review requested due to automatic review settings November 2, 2026 22:55

Copilot AI reviewed Nov 2, 2026

shoumikhin changed the title ~~XNNPACK: fix enable_bf16 load failures for bmm and ops without bf16 support~~ XNNPACK: fix enable_bf16 load failures and BatchNorm folding into a 3-D linear output Nov 2, 2026

JakeStevens approved these changes Nov 3, 2026

View reviewed changes

shoumikhin merged commit 7bf0303 into pytorch:main Nov 3, 2026
221 of 222 checks passed

shoumikhin mentioned this pull request Nov 3, 2026

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

Open

shoumikhin mentioned this pull request Nov 3, 2026

[v1.6.0] Release Schedule and Tracker #23608

Open

shoumikhin added a commit that referenced this pull request Nov 3, 2026

Merge release/1.6 into the #24464 cherry-pick

21014eb

Conversation

shoumikhin commented Nov 2, 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

Tests

Uh oh!

pytorch-bot Bot commented Nov 2, 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/24464

❗ 1 Active SEVs

⏳ No Failures, 13 Pending

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

shoumikhin commented Nov 2, 2026

Uh oh!

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

Uh oh!

PR Review: #24464

Summary

Code Quality

Testing

API Design

Performance

Recommendation

Uh oh!

JakeStevens left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

shoumikhin commented Nov 2, 2026

Uh oh!

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

Uh oh!

PR Review: #24464

Summary

Code Quality

Recommendation

Uh oh!

shoumikhin commented Nov 2, 2026

Uh oh!

Uh oh!

shoumikhin commented Nov 3, 2026

Uh oh!

shoumikhin commented Nov 3, 2026

Uh oh!

pytorchbot commented Nov 3, 2026

Cherry picking #24464

Uh oh!

shoumikhin commented Nov 3, 2026

Uh oh!

pytorchbot commented Nov 3, 2026

Cherry picking #24464

Uh oh!

Reviewers

shoumikhin commented Nov 2, 2026 •

edited

Loading

pytorch-bot Bot commented Nov 2, 2026 •

edited

Loading

claude Bot commented Nov 2, 2026 •

edited

Loading

claude Bot commented Nov 2, 2026 •

edited

Loading