conformance.
Revert r19137 and keep the testing case. Commit a fix that combines
substitutions from the specialized protocol conformance and substitutions from
the ApplyInst; then uses the full substitution list in substGenericArgs.
I had a small SIL testing case that runs "sil-opt -devirtualize", but due to
rdar://18120894, the testing case failed to work.
rdar://17440222
Performance -----
Before:
Totals,54,114129,114129,114129,0,0 (O)
Totals,54,81957,81957,81957,0,0 (Ounchecked)
Totals,54,83157,83157,83157,0,0 (run 2 of Ounchecked)
After:
Totals,54,109847,109847,109847,0,0 (O)
Totals,54,80301,80301,80301,0,0 (Ounchecked)
Swift SVN r21442
that seaches for point-of-construction for classes outside of the function that
does the devirtualization. Now we have a utility that devirtualizes a class
given a ClassDecl. NFC.
Swift SVN r20946
Before this commit we scanned the vtables every time we wanted to know who are the subclasses of a class. Now we scan the vtables just once.
Swift SVN r20847
Devirtualization of inherited protocol conformances are not essential
for stdlib performance since in most cases the stdlib does not use class
types (in contrast to devirtualization of specialized protocol
conformances which /is/ essential). So for Seed 5 I am disabling this
for the reasons below:
We are not upcasting metatypes correctly and while debugging that I ran
into a case where in the protocol witness we had generic types as if
the protocol witness was potentially covariant in all arguments. This
caused the devirtualizer to subtitute in the witness type as
appropriate, but due to the covariant argument the devirtualizer did not
perform an upcast causing a verifier fail.
<rdar://problem/17823711>
Swift SVN r20612
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
In a few places we were calling into a function that just returned
T->hasArchetype(). This just changes those places to test it directly.
Swift SVN r19427
We fail devirtualizing a specialized protocol method because the number (1) of
substitutions obtained from looking in the witness table does not match up with
the number (2) of substitutions expected by the function signature substitution
code.
As a workaround until the type code is fixed, check for this condition and bail.
rdar://17399536
Swift SVN r19137
Dynamic languages are able to implement inline caches for virtual calls, but swift is statically compiled, so we have to guess the types at compile time. The early binding pass guesses that types at the bottom of the class hierarchy are not subclassed and emits direct calls to these passes. It converts class_method calls into the following code:
if (Instance is of time Foo) {
Foo::ping()
} else {
Instance->ping();
}
The check if an instance is of a specific type is inexpensive, it is simply a load+icmp sequence.
Swift SVN r18860
I added some helpers to ApplyInst that should hopefully linguistically eliminate
the issue by allowing users of the API to not need to remember that the self
substitution is first, but the self argument is last.
We should really just remove the dichotomy. But that is for after WWDC.
I also disabled devirtualization of inherited protocol conformances for
protocol_methods. This will be less likely to be used than specialized
protocol conformances protocol_method devirtualization (which is
currently).
<rdar://problem/16951124>
Swift SVN r18282
The only case which we were handling in the old code where the class
method was not dead was when we had an apply inst of the class method.
This commit simplifies all of the weird code therein by causing class
method optimization to go through the same optimization pathway as how
we optimize protocol methods and witness methods (i.e. we pattern match
on the apply and only replace the apply).
This makes the code much simpler and more readable.
Additionally while working on test cases I noticed that relying on
SILCombine to peephole convert_function creates phase ordering issues
since SILCombine does not cause additional optimizer iterations to run
implying that we can have a situation where we devirtualize, fail to
inline, then silcombine (which would allow us to optimize), but then
the pass manager does not go around another time. Thus I move that
operation into the devirtualizer itself since it is relatively simple to
do.
Also re-enable test/SILPasses/devirt_override.sil since we handle it
correctly now.
Swift SVN r17566
