Skip to content

Conversation

@ngimel
Copy link
Collaborator

@ngimel ngimel commented Oct 5, 2022

Currently index_select/index_add decompositions decompose to index or index_put ops. The problem with this is that index_select and index_add accept int32 indices while index doesn't. That leads to error in meta func for those decompositions. This PR adds non-performant support for int32 indices to index operations, to allow decompositions go through.

@pytorch-bot
Copy link

pytorch-bot bot commented Oct 5, 2022

🔗 Helpful Links

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

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

❌ 2 Failures

As of commit 3a243e0:

The following jobs have failed:

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

Copy link
Collaborator

@lezcano lezcano left a comment

Choose a reason for hiding this comment

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

This will be quite slow. Can this path be accessed from the Python API? If so, this may bite people.

TORCH_CHECK_INDEX(false, "tensors used as indices must be long, byte or bool tensors");
if (allow_int) {
if (scalarType != kLong && scalarType != kByte && scalarType != kBool && scalarType != kInt) {
TORCH_CHECK_INDEX(false, "tensors used as indices must be long, byte or bool tensors");
Copy link
Collaborator

Choose a reason for hiding this comment

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

or int

@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Oct 5, 2022
@ngimel
Copy link
Collaborator Author

ngimel commented Oct 5, 2022

This path is accessible from python, but it's not slower than it is today for users who have to use int32 indices for whatever reason (they'd need to manually convert them to int64), so I don't consider it "biting". When used in the decomposition the backend will generate a kernel directly for int32 indices.

@lezcano
Copy link
Collaborator

lezcano commented Oct 5, 2022

Yes... but also no. If you are creating an integer tensor, let it be for indexing or whatever, by default you are going to create it with dtype int32. If then you use it to index and PyTorch complains, then you'll just change the dtype in its constructor and move on. With this change, t[idx] will start working (much slowlier) with indices of type in32, so this will certainly bite people. I think we should think of a better long-term solution...

@ngimel
Copy link
Collaborator Author

ngimel commented Oct 5, 2022

Integer tensors by default are created with int64 dtype (functions like arange, randint and the like, converting python lists to tensors, indices returned by max and unique and sort), so accidentally running into int32 problem is not very likely.

@ngimel
Copy link
Collaborator Author

ngimel commented Oct 5, 2022

@pytorchbot merge -f "test failures unrelated"

@pytorchmergebot
Copy link
Collaborator

@pytorchbot successfully started a merge job. Check the current status here.
The merge job was triggered with the force (-f) flag. This means your change will be merged immediately, bypassing any CI checks (ETA: 1-5 minutes). If this is not the intended behavior, feel free to use some of the other merge options in the wiki.
Please reach out to the PyTorch DevX Team with feedback or questions!

@github-actions
Copy link
Contributor

github-actions bot commented Oct 5, 2022

Hey @ngimel.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.

facebook-github-bot pushed a commit that referenced this pull request Oct 7, 2022
…#86309)

Summary:
Currently index_select/index_add decompositions decompose to `index` or `index_put` ops. The problem with this is that `index_select` and `index_add` accept int32 indices while `index` doesn't. That leads to error in meta func for those decompositions. This PR adds non-performant support for int32 indices to `index` operations, to allow decompositions go through.

Pull Request resolved: #86309
Approved by: https://github.com/lezcano

Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/dc9c507d24d0c833cb09105177326f1f6bbe99c4

Reviewed By: seemethere

Differential Revision: D40166997

Pulled By: seemethere

fbshipit-source-id: 812a8b8e5d7088ba20586ced63ea294ea994fa0f
@github-actions github-actions bot deleted the ngimel/int_index branch April 6, 2024 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ciflow/trunk Trigger trunk jobs on your pull request cla signed Merged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants