-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Constraint System] Implement heuristics for linked operator expressions in the solver proper. #34399
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
[Constraint System] Implement heuristics for linked operator expressions in the solver proper. #34399
Conversation
…rload is (T,T)->T, with no (T,T)->U
…e types match existing binding choices
…n to speed up further searching
@swift-ci please smoke test compiler performance |
@swift-ci please test compiler performance |
This comment has been minimized.
This comment has been minimized.
successfully finding a solution by favoring operators already bound elsewhere. Favoring existing operator bindings often lets the solver find a solution fast, but it's not necessarily the best solution.
2967fe8
to
16ef6c5
Compare
order them first in the main disjunction partition.
`DisjunctionStep::shortCircuitDisjunctionAt`. This code is unnecessary because SIMD overloads are in their own partition, so the short circuiting will happen automatically.
hacks for now. There's some more disjunction pruning work to be done before we can remove this.
92e492e
to
423d6bd
Compare
@swift-ci please smoke test compiler performance |
@swift-ci please test compiler performance |
existingOperatorBindingsForDisjunction.
@swift-ci please test compiler performance |
@swift-ci please test source compatibility |
@swift-ci please test |
Build failed |
Build failed |
@swift-ci please test |
@swift-ci please test compiler performance |
Build failed |
@swift-ci please build toolchain |
Linux Toolchain (Ubuntu 16.04) Install command |
macOS Toolchain Install command |
selectDisjunction if both disjunctions are operator bindings.
ef48ad3
to
c4f43f5
Compare
@swift-ci please test source compatibility |
@swift-ci please smoke test compiler performance |
@swift-ci please test compiler performance |
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.
So happy to see more of these solving hacks removed!
are already bound elsewhere for existingOperatorBindingsForDisjunction, rather than also considering overload choices with the same type.
c4f43f5
to
2507a31
Compare
func method(_ arg: String, body: () -> [String]) {} | ||
|
||
func test(str: String, properties: [String]) { | ||
// expected-error@+1 {{the compiler is unable to type-check this expression in reasonable time}} |
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.
This isn't new, but a case I discovered when debugging the source compat failures. This compiles (very slowly) if you add a type annotation to param
below.
@swift-ci please smoke test |
@swift-ci please test compiler performance |
@swift-ci please smoke test OS X platform |
Summary for main fullUnexpected test results, excluded stats for RxCocoa No regressions above thresholds Debug-batchdebug-batch briefRegressed (0)
Improved (1)
Unchanged (delta < 1.0% or delta < 100.0ms) (2)
debug-batch detailedRegressed (0)
Improved (7)
Unchanged (delta < 1.0% or delta < 100.0ms) (250)
Releaserelease briefRegressed (0)
Improved (0)
Unchanged (delta < 1.0% or delta < 100.0ms) (3)
release detailedRegressed (0)
Improved (4)
Unchanged (delta < 1.0% or delta < 100.0ms) (253)
|
@swift-ci please smoke test |
This PR contains the first handful of commits from @gregomni in #26140, with some adjustments. Specifically:
selectDisjunction
.These heuristics together help the solver reach a solution fast for expressions with multiple operators chained together where the operands all have the same type.
Finding a solution fast allows the solver to do more aggressive pruning later on. Once this change lands, I'm going to work on pruning heuristics for generic overloads, which I think will finally let us remove
LinkedExprAnalyzer
and the hacks around favored constraints. Once those hacks are removed, the favoring mechanism can be used to suggest choices that are likely to work without worrying about correctness.All thanks to Greg for the approach taken in this PR!!