[Constraint solver] De-prioritize SIMD operators. #21231
Conversation
The new SIMD proposal introduced a number of new operators, the presence of which causes more "expression too complex" failures. Route around the problem by de-prioritizing those operators, visiting them only if no other operator could be chosen. This should limit the type checker performance cost of said operators to only those expressions that need them OR that already failed to type-check. Fixes rdar://problem/46541800.
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
| return false; | ||
|
|
||
| auto func = dyn_cast<FuncDecl>(value); | ||
| if (!func) |
There was a problem hiding this comment.
Nit: can combine two ifs into one !(func && function->isOperator()), and same could be done for nominal using De Morgan's Law :)
There was a problem hiding this comment.
I like breaking out the conditions here.
|
|
||
| // Check whether we have any SIMD operators. | ||
| bool foundSIMDOperator = false; | ||
| for (const auto &choice : choices) { |
There was a problem hiding this comment.
I'm not sure if it's actually worse to check if we have any simd operators and then sort, might be faster to simplify sort since there are not going to be thousands of operators anyway...
There was a problem hiding this comment.
I'm trying to avoid the malloc + copy for the common case.
There was a problem hiding this comment.
You can also use llvm::find_if to make it a bit smaller :)
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
Build failed |
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
DougGregor
force-pushed
the
simd-operator-type-check-perf-hack
branch
from
a9b6c48 to
052d4c1
Compare
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
Build failed |
|
@swift-ci please test |
|
Previous failure was a spurious one from LLDB: |
|
This optimization is safe and improves things a bit, so I'm going to go ahead and merge it. The more advanced hack in #21253 is also way more dicey, so I want to hold off on that. |
The new SIMD proposal introduced a number of new operators, the presence of
which causes more "expression too complex" failures. Route around the
problem by de-prioritizing those operators, visiting them only if no
other operator could be chosen. This should limit the type checker
performance cost of said operators to only those expressions that need
them OR that already failed to type-check.
Fixes rdar://problem/46541800.