Skip to content

fix: handle device in the same way as dtype in aten.full_like decomposition #3538

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

junstar92
Copy link
Contributor

Description

This PR extends the changes introduced in PR #3535 by applying similar handling for the device, which was previously missed.

In the original PR, the focus was on ensuring the correct propagation of dtype when using torch.full_like. However, torch.full_like also accepts a device argument, and if a device is explicitly passed, it may differ from the input tensor's device. This can result in the output tensor being created on a different device than the input, leading to device mismatch issues.

import torch
from torch.export._trace import _export
from torch_tensorrt.dynamo.lowering import get_decompositions

device0 = torch.device("cuda", index=0)
device1 = torch.device("cuda", index=1)


class MyModel(torch.nn.Module):
    def __init__(self):
        super().__init__()

    def forward(self, x):
        return torch.ones_like(x, dtype=torch.bool, device=torch.device("cuda", index=1))


model = MyModel().to(device0)
x = torch.randn(1, 10, dtype=torch.float16).to(device0)
ep = _export(model, (x,))
ep = ep.run_decompositions(get_decompositions(False))
gm = ep.module()
y = gm(x)

assert y.device == device1, f"{device1} expected, but got {y.device}"

Results:

AssertionError: cuda:1 expected, but got cuda:0

To prevent this, this PR ensures that the device is handled in the same way as dtype in the previous PR.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code follows the style guidelines of this project (You can use the linters)
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas and hacks
  • I have made corresponding changes to the documentation
  • I have added tests to verify my fix or my feature
  • New and existing unit tests pass locally with my changes
  • I have added the relevant labels to my PR in so that relevant reviewers are notified

@github-actions github-actions bot added component: lowering Issues re: The lowering / preprocessing passes component: api [Python] Issues re: Python API component: dynamo Issues relating to the `torch.compile` or `torch._dynamo.export` paths labels May 29, 2025
@github-actions github-actions bot requested a review from gs-olive May 29, 2025 04:11
@narendasan narendasan requested review from peri044 and apbose May 29, 2025 20:31
Copy link
Collaborator

@peri044 peri044 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla signed component: api [Python] Issues re: Python API component: dynamo Issues relating to the `torch.compile` or `torch._dynamo.export` paths component: lowering Issues re: The lowering / preprocessing passes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants