We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
The old invalidation lattice was incorrect because changes to control flow could cause changes to the
call graph, so we've decided to change the way passes invalidate analysis. In the new scheme, the lattice
is replaced with a list of traits that passes preserve or invalidate. The current traits are Calls and Branches.
Now, passes report which traits they preserve, which is the opposite of the previous implementation where
passes needed to report what they invalidate.
Node: I tried to limit the changes in this commit to mechanical changes to ease the review. I will cleanup some
of the code in a following commit.
Swift SVN r26449
Make the devirtualization functions take the actual type we're
devirtualizing (or speculatively devirutalizing) to, in order to
simplify the handling of metatypes. Remove the ClassDecl parameter from
these functions since it can always be derived from this type.
These changes set things up for more forthcoming improvements to
metatype handling.
As part of this I've simplified the function that determines if a member
is known to be 'final'. My expectation is that this can be further
simplified by removing the type parameter as part of other improvements
to metatype handling.
Swift SVN r26165
It turns out we're already at a point where we can easily pass the same
data along to the devirtualization functions, and were already passing
some of it.
Swift SVN r26040
This reverts commit r25946, reinstating r25944.
This had been preemptively reverted fearing it might have broken
test/SILPasses/devirt_value_metatypes.swift, but that turned out to not
have been the case.
Swift SVN r25959
This reverts commit r25947, reinstating r25943 with fixes.
This had been preemptively reverted fearing it might have broken
test/SILPasses/devirt_value_metatypes.swift, which it did. One of the
early exits that was hoisted should not have been moved.
I plan on another clean-up for that particular early exit in a
forthcoming commit.
Swift SVN r25958
This reverts commit r25948, reinstating r25942.
This had been preemptively reverted fearing it might have broken
test/SILPasses/devirt_value_metatypes.swift, but that turned out to not
have been the case.
Swift SVN r25957
This reverts commit r25949, reinstating r25941.
This had been preemptively reverted fearing it might have broken
test/SILPasses/devirt_value_metatypes.swift, but that turned out to not
have been the case.
Swift SVN r25956
It's clear from the surrounding code and our type system that these
checks can never fail. To ensure I wasn't overlooking something I added
asserts to this effect and ran the test suite. I remove the asserts
because they feel like clutter, but if anyone feels strongly I can add
them back.
Swift SVN r25944
Dispatching on value_metatype, which happens in cases like obj.dynamicType.method(), was broken.
Fix it and add a corresponding test-case.
Swift SVN r25892
No functional change here, and this is not in its final form. This is
just cut/paste/tweak to split the code apart in a first reasonable form.
Swift SVN r25769
Decouple devirtualizeClassMethod into an analysis part and a part that performs a real transformation.
This allows for early bail outs when trying to devirtualize a class_method call and thus avoids creating a duplicate class_method call invocation, which happened before in certain rare cases.
Swift SVN r25717
The only use of this was not terribly useful as an early-out since we
immediately test for two of the three cases.
At some point we can extend the code to actually walk back through
projections, but until then this just seems like noise.
Swift SVN r25668
We currently run the generic specialize after the devirtualizer because
devirtualization can unblock generic specialization. This patch saves the
newly created ApplyInsts and attempts to specialize only them.
Swift SVN r25576