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
Revert "[devirtualization] Begin refactor devirtualization code into first simple cases and then the general case."
This reverts commit r17288.
This reverts commit r17287.
To unblock the submission.
Swift SVN r17310
This in general should make the code far more readable and
understandable.
I am going to re-enable the inherited/specialized devirtualization in
subsequent commits.
Swift SVN r17287
See rdar://16676020 for details.
r17101 tries to solve r16761933 by checking non-direct recursions in
the call graph. We are in discussion of solving it in a different way.
Todo: figure out why r17101 causes a preformance regression.
Swift SVN r17265
This is important since it enables one to analyze the type of the
conformance that the witness table implements which may be different
than the original type. This follows the precedent where we return the
Substitutions from the protocol conformance tree traversal.
Swift SVN r17220
conformance is specialized, the function we are attempting to substitute
will have a generic self type. Make sure to substitute in substitutions
from the origin type (if it has them) before attempting to perform the
comparison inbetween the self pointer on the target function of the
devirtualization from the alloc_ref of the self pointer on the CMI.
Swift SVN r16909
Now we can devirtualize conformances like the following:
protocol P {
func doSomething()
}
struct X { }
struct B<T> : P {
func doSomething() { ... }
}
func whatShouldIDo(p : P) {
p.doSomething()
}
var b = B<X>()
whatShouldIDo(b)
rdar://16638833
Swift SVN r16874
We will trace across unchecked_ref_cast to find the class origin in
devirtualizer. This enables us to devirtualize class_method where the
operand needs to go across unchecked_ref_cast to reach the origin.
Swift SVN r16857
Given base class A and dervied class B, both with member functions f(),
to look for A.f in B's vtable, we should return SILFunction for B.f.
Before this commit, B's vtable will have entry for B.f, A's vtable will
have entry for A.f. When looking for A.f in B's vtable, it returns null.
And devirtualizer will look for A.f in A's vtable and resolve it to
SILFunction for A.f.
When replacing a class_method %1 : $A, #A.f!1 with a function ref to B.f,
we will have type checking issues for the apply instructions. So devirtualizer
will replace the argument of the apply instructions when necessary.
rdar://16681983
Swift SVN r16854
This cleans up the code and also allows devirtualization to cause
deserialization of witness table declarations.
<rdar://problem/16646818>
Swift SVN r16741
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
Previously if we had an inherited conformance, we would not put in an
upcast from the subtype to the parent when we called the devirtualized
protocol method.
Swift SVN r16644
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
