-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Make 'rawValue' and 'init(rawValue:)' inlinable for non-resilient enums #15589
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
Still needs tests, but I want to see if this happens to improve any benchmarks. (The JIRA has an ad hoc benchmark that could probably be added to the suite too.) |
@swift-ci Please benchmark |
@@ -146,6 +146,11 @@ static VarDecl *deriveRawRepresentable_raw(TypeChecker &tc, | |||
addGetterToReadOnlyDerivedProperty(tc, propDecl, rawType); | |||
getterDecl->setBodySynthesizer(&deriveBodyRawRepresentable_raw); | |||
|
|||
if (enumDecl->isExhaustive(nullptr) && | |||
enumDecl->getFormalAccessScope(nullptr, true).isPublic()) { |
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.
Can you add a comment like /* respectsVersioned */ true
?
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.
Looks good. We can do the same for equatable and hashable as well, however last time I looked the synthesized code for the no-payload case was really inefficient with switching over the tag when it could just bitcast the enum value to an integer and compare for equality. Anyway no need to investigate this in your PR.
Build comment file:Optimized (O)Regression (24)
Improvement (7)
No Changes (394)
Unoptimized (Onone)Regression (8)
Improvement (5)
No Changes (412)
Hardware Overview
|
Uh, interesting. Maybe things are getting inlined now where it would be better not to. This change also isn't 100% resilient because in theory you could decide |
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.
The benchmark results are ok. +/- 10% is most likely noise.
Okay, I've thought about this more and:
which I think means finding all of the examples in the stdlib where it matters and hand-rolling @slavapestov, thoughts? |
Further discovery: there is exactly one enum in the entire stdlib that would benefit from this: FloatingPointSign (the original cause of the bug). I think I'm going to just implement the synthesized members for that and punt on the original question (EDIT) for resilient libraries. |
Did that in #16043. Going to update this PR to only add |
Small potential perf win...or rather regain, since we apparently used to do this. It's a bit trickier to say whether we should do the same for resilient enums, since /in theory/ a later version of the library might decide to use different raw values. https://bugs.swift.org/browse/SR-7094
@swift-ci Please test |
@swift-ci Please test source compatibility |
@swift-ci Please smoke test compiler performance |
Build failed |
Build failed |
…ms (swiftlang#15589) Small potential perf win...or rather regain, since we apparently used to do this. It's a bit trickier to say whether we should do the same for resilient enums, since /in theory/ a later version of the library might decide to use different raw values. https://bugs.swift.org/browse/SR-7094 (cherry picked from commit 766acd4)
(
includingonly enums in libraries compiled without -enable-resilience)Small potential perf win...or rather regain, since we apparently used to do this.
SR-7094 / rdar://problem/38030106