[DO NOT MERGE] Inline data and dataprotocol #21165
Conversation
Previously the cast optimizer bailed out on any conformance with
requirements.
We can now constant-propagate this:
```
protocol P {}
struct S<E> {
var e: E
}
extension S : P where E == Int {}
func specializeMe<T>(_ t: T) {
if let p = t as? P {
// do fast things.
}
}
specializeMe(S(e: 0))
```
This turns out to be as simple as calling the TypeChecker.
<rdar://problem/46375150> Inlining does not seem to handle
specialization properly for Data.
|
@swift-ci benchmark. |
|
@swift-ci test source compatibility. |
|
@swift-ci test. |
Build comment file:Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibs
How 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 |
|
@itaiferber Let me know if the commits on this branch solve the immediate I still see the following regressions: I haven't looked at any individually. Are these expected regressions? I'm actually surprised that DataCreateMedium still lags, because the Note that I see a ton of code being inlined now from Data's Sequence |
|
Build failed |
|
@atrick Thanks so much for putting in the effort on this stuff! Our concerns about |
|
@atrick Upon reflection, it's entirely possible that we haven't conformed |
|
@airspeedswift @atrick @milseman It looks like we're likely hitting this because |
|
IMO, we should fix |
|
@milseman @airspeedswift Should I file a Radar or should we track this in 30541077? |
|
@atrick Otherwise these changes are great and unblock us! |
|
Wherever, I'll try to push it soon. |
|
@milseman I just filed 46601459 so we can track this appropriately internally too. Thanks for the quick turnaround! |
This allows expensive dynamic runtime checks like this: unconditional_checked_cast_addr Array<UInt8> in %array : $*Array<UInt8> to ContiguousBytes in %protocol : $*ContiguousBytes To be converted into: %value = init_existential_addr %existential : $*ContiguousBytes, $Array<UInt8> store %array to %value : $*Array<UInt8>
Handle the unconditional_checked_cast case. This involved a major cleanup/rewrite of the utility for analyzing existential types. Rewrite potentially fixes some latent bugs in the ExistentialSpecializer that I found by code inspection. There still appears to be a bug where it bit-casts an opened existential to a concrete type, but I believe that code path is disabled.
This adds three more optimizer fixes, in addition to the one that was already committed, in order to fix the performance of the generic Data initializer's dynamic customization.