Skip to content

Fix conversion of values in libtorch agnostic tests #155115

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

Conversation

AlekseiNikiforovIBM
Copy link
Collaborator

Due to different byteorder,
when copying data, it has to be put into last bytes to ensure that int32_t converted to int64_t keeps same value. Same has to be done when it's converted back.

This change fixes test
TestLibtorchAgnosticCPU::test_my_ones_like_cpu
from
cpp_extensions/libtorch_agnostic_extension/test/test_libtorch_agnostic.py on s390x.

Copy link

pytorch-bot bot commented Jun 4, 2025

🔗 Helpful Links

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

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

✅ You can merge normally! (1 Unrelated Failure)

As of commit 5e7fe14 with merge base ab65581 (image):

UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:

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

@AlekseiNikiforovIBM AlekseiNikiforovIBM added topic: not user facing topic category ciflow/s390 s390x-related CI jobs labels Jun 4, 2025
Skylion007
Skylion007 previously approved these changes Jun 4, 2025
@Skylion007 Skylion007 dismissed their stale review June 4, 2025 14:37

let someone else look at it

@jcaip jcaip added the triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module label Jun 5, 2025
@AlekseiNikiforovIBM AlekseiNikiforovIBM requested a review from a team as a code owner June 18, 2025 12:56
@AlekseiNikiforovIBM
Copy link
Collaborator Author

@pytorchbot rebase

@pytorchmergebot
Copy link
Collaborator

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

@pytorchmergebot
Copy link
Collaborator

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

@pytorchmergebot pytorchmergebot force-pushed the s390x_libtorch_agnostic branch from 60964d5 to c78ce6c Compare June 23, 2025 12:38
@AlekseiNikiforovIBM
Copy link
Collaborator Author

Could you please take a look at this PR again? I'm looking at docker build failure separately, it is not relevant to this change.

@AlekseiNikiforovIBM
Copy link
Collaborator Author

@pytorchbot rebase

@pytorchmergebot
Copy link
Collaborator

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

@pytorchmergebot
Copy link
Collaborator

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

@AlekseiNikiforovIBM
Copy link
Collaborator Author

@pytorchbot rebase

@pytorchmergebot
Copy link
Collaborator

@pytorchbot started a rebase job onto refs/remotes/origin/viable/strict. Check the current status here

@pytorchmergebot
Copy link
Collaborator

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

@pytorchmergebot pytorchmergebot force-pushed the s390x_libtorch_agnostic branch from 7a41f76 to c2e5e2c Compare July 8, 2025 09:12
Due to different byteorder,
when copying data, it has to be put into last bytes to ensure
that int32_t converted to int64_t keeps same value.
Same has to be done when it's converted back.

This change fixes test
TestLibtorchAgnosticCPU::test_my_ones_like_cpu
from
cpp_extensions/libtorch_agnostic_extension/test/test_libtorch_agnostic.py
on s390x.
@AlekseiNikiforovIBM AlekseiNikiforovIBM force-pushed the s390x_libtorch_agnostic branch from c2e5e2c to 5e7fe14 Compare July 8, 2025 11:46
@AlekseiNikiforovIBM
Copy link
Collaborator Author

Could you please take a look at this change again?

@huydhn huydhn requested a review from Skylion007 July 18, 2025 17:09
@AlekseiNikiforovIBM
Copy link
Collaborator Author

@pytorchbot merge

@pytorch-bot pytorch-bot bot added the ciflow/trunk Trigger trunk jobs on your pull request label Aug 4, 2025
@pytorchmergebot
Copy link
Collaborator

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

Advanced Debugging
Check the merge workflow status
here

Copy link
Collaborator

@albanD albanD left a comment

Choose a reason for hiding this comment

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

@huydhn can you give details on why this is needed and why this is ok to do?

@huydhn
Copy link
Contributor

huydhn commented Aug 5, 2025

@albanD This is one of the PR to support s390x that @AlekseiNikiforovIBM brought up on Slack, and then to our OH few weeks ago as there wasn't any progress on the PR. I stamped it after searching the code base and saw similar usage https://github.com/search?q=repo%3Apytorch%2Fpytorch%20__BYTE_ORDER__&type=code. I thought that it was safe because the codepath for __ORDER_BIG_ENDIAN__ is added while the rest stayed the same and the change looks simple enough. What do you think of this change?

FYI, there is another more complex one that is still open #151447

@albanD
Copy link
Collaborator

albanD commented Aug 5, 2025

I am confused why this PR is needed to begin with since both sides have the same endianess?

@AlekseiNikiforovIBM
Copy link
Collaborator Author

AlekseiNikiforovIBM commented Aug 6, 2025

I am confused why this PR is needed to begin with since both sides have the same endianess?

There was a test failure in TestLibtorchAgnosticCPU::test_my_ones_like_cpu. The issue is that, for example, int (4 bytes) value is put into long (8 bytes), and used as long.

Let's say number was 305419896 (0x12345678).

Originally value was put into first 4 bytes of long, so we get 0x78 0x56 0x34 0x12 0x00 0x00 0x00 0x00 in memory, which is also 0x12345678 even as long. But on big endian we got 0x12 0x34 0x56 0x78 0x00 0x00 0x00 0x00 in memory, which is actually 0x1234567800000000 as long, which is a different value, value of 1311768464867721216.

So, with this change we actually put it as 0x00 0x00 0x00 0x00 0x12 0x34 0x56 0x78 into memory on big endian system, which is also 0x12345678 as long on big endian system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ciflow/s390 s390x-related CI jobs ciflow/trunk Trigger trunk jobs on your pull request Merged open source topic: not user facing topic category triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants