Rather than calling getSubstitutions() in various places on the apply
that we are cloning the body of, pass the substitution list in
directly when creating the cloner.
This is not interesting for the generic specializer, but is important in
mandatory inlining when we go to inline an apply of a partial apply,
where we need to use the full list of substitutions for both.
Swift SVN r18951
Mandatory-inlined (aka transparent functions) are still treated as if they
had the location and scope of the call site. <rdar://problem/14845844>
Support inline scopes once we have an optimizing SIL-based inliner
Patch by Adrian Prantl.
Swift SVN r18835
Add a new SpecializingCloner that will contain the
generic-specialization-specific functionality needed by that pass. This
inherits from TypeSubCloner, which I will move into a separate file in a
future commit after further refactoring.
Swift SVN r18791
check whether any of the substitutions are dependent rather
than checking whether the function's substituted type is
dependent.
This can't currently come up for user functions because Swift
doesn't permit type arguments to be given explicitly; hence a
dependent type argument will necessarily appear somewhere in
the substituted signature. However, it's still possible in
the basic SIL model, and Joe's fix to default argument
initializers was just an obvious example.
Swift SVN r18768
This is working under the assumption that every class is in a certain
sense its own super class (or we are allowing it to be so for these
casts).
Swift SVN r18020
From discussions with Joe I thought that we were not doing this cast. I
am looking into now if the same thing can happen with super_to_archetype
(i.e. identity cast) is supported.
rdar://16892732
Swift SVN r17988
- Continue adding support for checked downcasts of array types (rdar://problem/16535104)
- Fix non-bridged array conversions post-r17868
- Fix rdar://problem/16773693
- Add tests for NSArray coercions to and from Array<T>
Swift SVN r17957
This eliminates the possibility of references to shared functions
without bodies from being exposed by the mandatory inliner.
This does not affect performance in any manner since after mandatory
inlining, we can always specialize in the function that was just inlined
into.
rdar://16809311
Swift SVN r17803
protocol conformances.
Without this we can not look up protocol conformances correctly after
specialization if the devirtualization applies to the relevant
specialized type.
Swift SVN r16873
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
This also teaches IRGen not to emit WitnessTable declarations. This
causes them to be left as unknown symbols in the resulting executable.
Swift SVN r15361
Pass in the context generic parameters that correspond to the substitution vector in Substitution::subst. When we build the type substitution map, also collect the conformances from the substitutions into a map we can use to fill in those conformances in substituted substitutions where necessary, without relying on the '.Archetype' field.
Swift SVN r14964
Have SILType::subst and SILFunctionType::subst always visit the interface types of a SILFunctionType. Fix up some problems in the specializer this exposed by having it correctly apply interface type substitutions to the function type of a specialized function and contextualized substitutions to the body.
Swift SVN r13714
With this change we are able to specialize generic recursive functions.
There are a few recursive generic functions in our String representation
and in qsort.
This patch accelerates all of the String benchmarks.
Swift SVN r13643
specialize on polymorphic arguments.
This can be enabled with: -sil-devirt-threshold 500.
It currently improves RC4 (when enabled) by 20%, but will be much more
important after Michael's load elimination with alias analysis lands.
This implementation is suitable for experimentation. Superficial code
reviews are also welcome. Although be warned that the design is overly
complex and I plan to rewrite it. I initially abandoned the idea of
incrementally specializing one function at a time, thinking that we
need to analyze full chains. However, I since realized after talking
to Nadav that the incremental approach can be made to work. A lot of
book-keeping will go away with that change.
TODO:
- Resolve protocol argument types. Currently we assume they can be
reinitialized at applies, but I don't think they can unless they are
@inouts. This is an issue with the existing local devirtualizer
that prevents it working across calls.
- Properly mangle the specialized methods. Find existing
specializations by demangling rather than maintaining a map.
- Rewrite the logic for specializing chains for simplicity.
- Enable by default.
Swift SVN r13642
Now the pass does not need to know about the pass manager. We also don't have
runOnFunction or runOnModule anymore because the trnasformation knows
which module it is processing. The Pass itself knows how to invalidate the
analysis, based on the injected pass manager that is internal to the
transformation.
Now our DCE transformation looks like this:
class DCE : public SILModuleTransform {
void run() {
performSILDeadCodeElimination(getModule());
invalidateAnalysis(SILAnalysis::InvalidationKind::All);
}
};
Swift SVN r13598
