Skip to content

Use [u]int64 -> FloatingPoint conversions even on 32b targets #70541

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

Merged

Conversation

stephentyrone
Copy link
Contributor

@stephentyrone stephentyrone commented Dec 19, 2023

This means that we'll end up going int32 -> int64 -> float/double sometimes, but LLVM knows how to optimize away the intermediate conversion so we end up with just a normal 32b->float conversion as desired, and we get much, much better performance on oddball platforms like arm64_32.

…tforms.

This means that we'll end up going int32 -> int64 -> float/double sometiems, but LLVM knows how to optimize away the intermediate conversion so we end up with just a normal 32b->float conversion as desired, and we get much, much better performance on oddball platforms like arm64_32.
@stephentyrone stephentyrone requested a review from a team as a code owner December 19, 2023 18:35
@stephentyrone
Copy link
Contributor Author

@swift-ci test

@glessard
Copy link
Contributor

@swift-ci please benchmark

Copy link
Contributor

@Azoy Azoy left a comment

Choose a reason for hiding this comment

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

Looks good 2 me! Standard library is the gift that keeps on giving!

@stephentyrone
Copy link
Contributor Author

@glessard the CI bencharks only test targets where there's no difference at all from this change, sadly.

@natecook1000
Copy link
Member

With integer conversions, there's no chance of a difference in rounding, correct? I remember that we had a bunch of platform-specific problems around NSNumber bridging when changing one of these initializers, but I'm pretty sure that was a float-to-float conversion.

@stephentyrone
Copy link
Contributor Author

@swift-ci smoke test linux

@stephentyrone
Copy link
Contributor Author

stephentyrone commented Dec 19, 2023

With integer conversions, there's no chance of a difference in rounding, correct?

The only way we'd see a change here is if the generic conversion routine had a bug that we'd now avoid, which could be a hassle but also a change we'd want to make. We're reasonably confident that this isn't the case for standard library types, but the input space is too large to test exhaustively, so we can't be certain.

@stephentyrone stephentyrone merged commit 154454e into swiftlang:main Dec 20, 2023
@stephentyrone stephentyrone deleted the 64b-ought-to-be-enough-for-anybody branch December 20, 2023 01:29
meg-gupta pushed a commit to meg-gupta/swift that referenced this pull request Dec 21, 2023
…tforms. (swiftlang#70541)

This means that we'll end up going int32 -> int64 -> float/double sometiems, but LLVM knows how to optimize away the intermediate conversion so we end up with just a normal 32b->float conversion as desired, and we get much, much better performance on oddball platforms like arm64_32.
Catfish-Man pushed a commit to Catfish-Man/swift that referenced this pull request Jan 19, 2024
…tforms. (swiftlang#70541)

This means that we'll end up going int32 -> int64 -> float/double sometiems, but LLVM knows how to optimize away the intermediate conversion so we end up with just a normal 32b->float conversion as desired, and we get much, much better performance on oddball platforms like arm64_32.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants