-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Add fast paths for generic floating-point-to-integer conversion #33889
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
base: main
Are you sure you want to change the base?
Conversation
/cc @troughton |
@stephentyrone What do you think of this approach? |
3f94c64
to
a4ab537
Compare
@swift-ci test |
@nkcsgexi I'm not sure if you're the person to ask about this, but since you've worked on the ABI checker recently, perhaps you'd know: This change is failing the ABI stability check because there's now a concrete implementation of a protocol requirement, where previously these types used the default implementation; the ABI checker wants an availability annotation. However, if I add an availability annotation, then there will be an error when compiling because the compiler wants the concrete implementation to be unconditionally available everywhere. What is the ABI-stable way to override a default implementation of a protocol requirement? Is this just a false positive, and if so, how would I silence the checker? |
@xwu this doesn't seem to be a false positive to me because the compiler also confirmed that the concrete implementation should be unconditionally everywhere, which cannot be true since it's a new definition. @lorentey , what would you recommend for overriding a default implementation of a protocol requirement in an ABI stable way? |
The new concrete implementations will have to be marked |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@swift-ci test macOS platform |
@swift-ci benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
This comment has been minimized.
This comment has been minimized.
@swift-ci test Linux platform |
Build failed |
Wow, using
|
This comment has been minimized.
This comment has been minimized.
100848e
to
5dbe1a9
Compare
@swift-ci smoke test macOS platform |
@swift-ci smoke test Linux platform |
Let's see if the mysterious compiler problem has improved any in six months... |
@swift-ci benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
…ific mismatched type (see swiftlang#36267)
This comment has been minimized.
This comment has been minimized.
Mmm, spoke too soon, it seems. Forgot that it takes running the full set of tests to produce the error:
|
@swift-ci test |
Build failed |
@swift-ci test macOS platform |
Build failed |
Here, we use a similar approach as that in #33826 to create some fast paths for conversion of generic floating-point values to integers.
With the slightly different design of the integer protocols, it's necessary to create concrete implementations of the required initializer (hence their addition to
IntegerTypes.swift.gyb
). These ultimately call the protocol extension methodSelf._convert
as a fallback; for conversion from any floating-point values of known format, however, the fast paths here would apply.