🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki

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:

• ROCm MI2xx CI/CD workflows failing due to : download from https://api.github.com/repos/pytorch/pytorch timed out.

✅ No Failures

As of commit 69bdfd0 with merge base 6737e2c ():
💚 Looks good so far! There are no failures yet. 💚

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

@pytorchbot label "module: inductor"

@eellison Thank you for your review. I have fixed the CI errors. Please let me know if any further modifications are needed, and kindly help run the CI checks again.

@soulitzer Thank you for the review. I have gained a new understanding of this part. In Eager mode, the C++ implementation is directly invoked, while in Inductor mode, Python lowering performs type checks. I have now removed the assertion checks for Python lowering and fully delegated type handling to the C++ implementation to maintain logical consistency. The tests I conducted passed successfully.

Thanks for the update, that sounds good. Could you add a test?

@soulitzer Removing the assert x.get_dtype() == src.get_dtype() is not a good idea, so the solution has been reverted to the original approach: type_promotion_kind=ELEMENTWISE_TYPE_PROMOTION_KIND.NO_OPMATH. We have added tests, which have already passed.

@soulitzer ‌Testing type promotion
import torch

def test_slice_scatter_dtype_behavior():
    """Test slice_scatter in both Eager and Inductor modes"""

    print("=== Testing slice_scatter ===\n")

    # Test case
    target = torch.zeros(4, dtype=torch.float32)
    source = torch.tensor([1, 2], dtype=torch.int64)

    print(f"Target: {target.dtype}, Source: {source.dtype}")

    # Eager mode
    result_eager = target.slice_scatter(source, start=0, end=2)
    print(f"Eager: {result_eager.dtype}")

    # Inductor mode
    try:
        compiled_fn = torch.compile(lambda t, s: t.slice_scatter(s, start=0, end=2))
        result_inductor = compiled_fn(target, source)
        print(f"Inductor: {result_inductor.dtype}")

        # Compare
        dtype_match = result_eager.dtype == result_inductor.dtype
        value_match = torch.allclose(result_eager, result_inductor)

        print(f"Match: {'✅' if dtype_match and value_match else '❌'}")

    except Exception as e:
        print(f"Inductor failed: {e}")

if __name__ == "__main__":
    test_slice_scatter_dtype_behavior()
~                                           


=== Testing slice_scatter ===

Target: torch.float32, Source: torch.int64
Eager: torch.float32
Inductor: torch.float32
Match: ✅

Removing the assert x.get_dtype() == src.get_dtype() is not a good idea

Why not? We don't have that assumption in eager?

ELEMENTWISE_TYPE_PROMOTION_KIND.NO_OPMATH

Hmm, but my earlier point was that we don't actually do type promotion in this op.

@soulitzer
Removing the assert x.get_dtype() == src.get_dtype() ‌The test cases are failing

@soulitzer The ELEMENTWISE_TYPE_PROMOTION_KIND.NO_OPMATH test passes. I suspect it actually performs non-trivial work beyond simple type promotion, although the detailed mechanics remain unclear at this stage.

I suspect its not doing type promotion based on this example:

>>> a = torch.zeros(8, 8, dtype=torch.float32)
>>> b = torch.ones(2, 8, dtype=torch.float64)
>>> a.slice_scatter(b, start=6).dtype
torch.float32
>>>

Are you testing that?

I suspect its not doing type promotion based on this example:

>>> a = torch.zeros(8, 8, dtype=torch.float32)
>>> b = torch.ones(2, 8, dtype=torch.float64)
>>> a.slice_scatter(b, start=6).dtype
torch.float32
>>>

Are you testing that?

YES
(mtorch) gaoyufeng@DESKTOP-QT4IL9F:~/code/pytorch$ python
Python 3.12.11 | packaged by Anaconda, Inc. | (main, Jun 5 2025, 13:09:17) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import torch
a = torch.zeros(8, 8, dtype=torch.float32)
b = torch.ones(2, 8, dtype=torch.float64)
a.slice_scatter(b, start=6).dtype
torch.float32

YES
(mtorch) gaoyufeng@DESKTOP-QT4IL9F:~/code/pytorch$ python
Python 3.12.11 | packaged by Anaconda, Inc. | (main, Jun 5 2025, 13:09:17) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import torch
a = torch.zeros(8, 8, dtype=torch.float32)
b = torch.ones(2, 8, dtype=torch.float64)
a.slice_scatter(b, start=6).dtype
torch.float32

Sorry to clarify, what I mean to ask is if you have checked parity for this example between the inductor lowering and the op? I'm asking because I don't see it in the test case "test_slice_scatter_dtype_consistency", could you add it there?

@soulitzer Thank you for your review. I apologize, as my previous test was incorrect. Removing the assertion x.get_dtype() == src.get_dtype() was the right decision. I have updated the test code accordingly. Thanks again for the review.

Thanks for the update. For the test failures, let's just skip in test/inductor/test_torchinductor_codegen_dynamic_shapes.py

@soulitzer Thanks for the review.. Can we merge it?

We may have to fix a test failure to pass CI. See my previous comment here #160851 (comment)

❌ 🤖 pytorchbot command failed:

@pytorchbot: error: argument command: invalid choice: 'marge' (choose from 'merge', 'revert', 'rebase', 'label', 'drci', 'cherry-pick')

usage: @pytorchbot [-h] {merge,revert,rebase,label,drci,cherry-pick} ...

Try @pytorchbot --help for more info.

@pytorchbot merge

Successfully rebased fix-slice-scatter-dtype-consistency onto refs/remotes/origin/viable/strict, please pull locally before adding more changes (for example, via git checkout fix-slice-scatter-dtype-consistency && git pull --rebase)

@pytorchbot merge

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team