Repository navigation
Conversation
…torch#24176) Summary: `add.Scalar(Tensor self, Scalar other, Scalar alpha=1)` takes `alpha` positionally, but `add.Tensor(Tensor self, Tensor other, *, Scalar alpha=1)` takes it as keyword-only, and the same holds for `sub`. When `alpha` was the third positional argument, `get_replacement` passed it through `*args[2:]`, and building the `.Tensor` node raised `RuntimeError: aten::add() takes 2 positional argument(s) but 3 was/were given`. The 3-argument path now passes `args[:2]` and moves `alpha` into `kwargs`, so `get_replacement` always gets 2 args and no longer forwards extra ones. The Arm `ReplaceScalarWithTensorByProfilePass` subclass routes through the same base `call_operator`, so it gets the fix too for edge `add/sub.Scalar`. `torch.ops.aten.add/sub.Scalar` with a positional `alpha` still pass through unreplaced, as before. The changed path previously always raised, so no graph that worked before is affected. Found by the Jarvis nightly operator tests: `test_aten_add_scalar_out` fails 13 of 24 FACTO cases (every case with an explicit `alpha`) on nxp, DLA and Artemis v3/v4. ] Differential Revision: D127746753
Summary: `pow.Tensor_Scalar(int32, 2.0)` returns float32, but the `mul.Tensor(x, x)` chain that `ReplacePowWithMulPass` emits stays int32. The pass copied the float32 `meta` onto the int32 `mul` nodes, so the lowered program's output dtype no longer matched the eager reference. The pass now gives up when the input dtype differs from the `pow` output dtype. Found by the Jarvis nightly operator tests: `test_pow_Tensor_Scalar_out` cases 14 and 23 (int32 input, exponent 2.0) fail on nxp, DLA, Artemis v3/v4 and CPU with `The label tensor ... dtype shall be torch.int32, but now is torch.float32`. Differential Revision: D127746754
Summary: `div.Tensor_mode(a, b, rounding_mode=None)` is true division. The HiFi `div_out_mode` sent `None` to the non-optimized path, where `mode_is_trunc` was false and the code fell through to `floor_divide` (its comment assumed the mode "must be floor"). So `7 / 2` returned 3 and `-7 / 2` returned -4. The kernel now delegates to `div_out` when `mode` has no value, which is what the portable and Fusion G3 `div_out_mode` already do. Found by the Jarvis nightly operator tests: on nxp_rt600 (HiFi4), `test_aten_div_out_mode` fails every case where FACTO picks `rounding_mode=None` (25 of 50, all with `max_abs_diff ≈ 0.99`). DLA, which uses a different kernel, passes all 50. Differential Revision: D127746755
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24178
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 817eeeb with merge base a90db24 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
@aliafzal has exported this pull request. If you are a Meta employee, you can view the originating Diff in D127746755. |
This PR needs a
|
Summary:
div.Tensor_mode(a, b, rounding_mode=None)is true division. The HiFidiv_out_modesentNoneto the non-optimized path, wheremode_is_truncwas false and the code fell through tofloor_divide(its comment assumed the mode "must be floor"). So7 / 2returned 3 and-7 / 2returned -4. The kernel now delegates todiv_outwhenmodehas no value, which is what the portable and Fusion G3div_out_modealready do.Found by the Jarvis nightly operator tests: on nxp_rt600 (HiFi4),
test_aten_div_out_modefails every case where FACTO picksrounding_mode=None(25 of 50, all withmax_abs_diff ≈ 0.99). DLA, which uses a different kernel, passes all 50.Differential Revision: D127746755