-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Change _withUnsafeGuaranteedRef to use Builtin.convertUnownedUnsafeToGuaranteed. #30033
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
[stdlib] Change _withUnsafeGuaranteedRef to use Builtin.convertUnownedUnsafeToGuaranteed. #30033
Conversation
@swift-ci test |
@swift-ci benchmark |
@swift-ci test source compatibility |
…dUnsafeToGuaranteed. This builtin (which lowers to raw SIL that doesn't use an actual builtin instruction) allows us to access an unmanaged value at +0 with a language guarantee rather than relying on the optimizer. Previously, we did not do this directly since without OSSA, we were scared that the frontend/optimizer would not be able to safely emit this code. Now that we have ownership ssa, we are able to ensure that the frontend always copies the +0 value passed into the closure if the value +0 escapes from the closure (either via a return, storing into memory, or by passing off as a +1 parameter to a function). rdar://59735604
63061af
to
7820ddc
Compare
@swift-ci test |
@swift-ci benchmark |
@swift-ci test source compatibility |
@swift-ci test |
@swift-ci benchmark |
As a follow-up we should remove UnsafeGuaranteedPeephole.cpp |
@aschwaighofer SGTM |
Performance: -OCode size: -OPerformance: -Osize
Code size: -OsizePerformance: -OnoneCode 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Is there a way to add a test to catch future regressions, like the one that broke the original implementation?
Builtin.unsafeGuaranteedEnd(token) | ||
return result | ||
var tmp = self | ||
let fakeBase: Int? = nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should explain what fakeBase
is for, and why a "real" base isn't actually required in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is that the user is stating with this API that they are putting a _fixLifetime around as per the documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@atrick I am happy to do that in a follow on commit.
Build failed |
@lorentey best way is by adding a benchmark |
@swift-ci smoke test linux platform |
linux failure was in sourcekit-lsp everything else passed. |
@swift-ci smoke test linux platform |
@lorentey I have the perfect benchmark for this actually already. I have a version of Prims that uses UnsafeUnowned directly using Unmanaged, but instead of using _wUGR, it uses takeUnretainedValue I will add a version that uses this API instead and land it before this change. |
@gottesmm Ah, this reminded me I still have a benchmark somewhere with three binary tree implementations (vanilla ADT with |
(But what I meant is a unit test that simply checks for unexpected retain/release calls, so that we get an immediate and clear signal. Benchmarks don't run on every merge...) |
Ok. I’ll do it in a follow on commit. Clack needs this. |
Or nm. Won’t let me do it on my phone. |
I’m going to put in the test and retest |
I am just going to use Karoy's benchmark that just landed to show the impact here. Then I am going to merge and fix the other issues people brought up in a follow on commit. |
@swift-ci smoke benchmark |
5 similar comments
@swift-ci smoke benchmark |
@swift-ci smoke benchmark |
@swift-ci smoke benchmark |
@swift-ci smoke benchmark |
@swift-ci smoke benchmark |
@swift-ci benchmark |
Finally, swift-ci does my bidding! |
I'm going to merge this now. The benchmarks will show up when they do. Karoy says locally he validated the perf. |
!!! Couldn't read commit file !!! |
1 similar comment
!!! Couldn't read commit file !!! |
This builtin (which lowers to raw SIL that doesn't use an actual builtin
instruction) allows us to access an unmanaged value at +0 with a language
guarantee rather than relying on the optimizer.
Previously, we did not do this directly since without OSSA, we were scared that
the frontend/optimizer would not be able to safely emit this code. Now that we
have ownership ssa, we are able to ensure that the frontend always copies the +0
value passed into the closure if the value +0 escapes from the closure (either
via a return, storing into memory, or by passing off as a +1 parameter to a
function).
rdar://59735604