This shaves about 10% off the number of solution states explored when
type-checking the standard library, although it doesn't improve
overall time by much. In a more targeted benchmark, 1 + 2.0 + 1, we
get a 21% speedup.
Swift SVN r11033
Provides a 4% speedup type-checking the standard library. This
optimization brings the global constraint graph within 2% of the prior
solution, and prevents us from creating multiple constraint graphs per
constraint system, so flip the switch to always use the global
constraint graph.
Swift SVN r11003
Whenever we bind a type variable or merge two type variables, add
those constraints that could be affected to a worklist. Simplification
continues processing constraints in the worklist until the worklist is
empty.
This change reduces the number of constraints that we visit but can't
simplify by ~13x in the standard library, but this doesn't translate
into a performance win. More investigation is needed here.
Note that the worklist is only in use when we have a global constraint
graph, which isn't enabled by default yet.
Swift SVN r10936
Make the constraint graph into a scoped data structure that tracks the
changes that occur within a given scope, undoing those changes when
the scope is popped off the scope stack. The constraint graph's scopes
align with the constraint solver's scopes. Synchronize the solver's
constraint addition/removal operations with the constraint graph, and
improve our verification to make sure these stay in sync.
This is still a work in progress. Type checking the standard library
is about 5% slower with the per-constraint-system constraint graph
rather than building a new constraint graph each iteration *after*
simplification, and there are two intruiging test failures that appear
to be the constraint solver breaking its own invariants. Therefore,
this feature is off by default. See the ConstraintSystem constructor
for the one-line change to turn it back on.
Swift SVN r10927
Rather than building the constraint graph after simplification and
then never modifying it, build the constraint graph before
simplification and update it as simplification adds/removes
constraints. This is a step toward two separable performance goals:
(1) having a single constraint graph that evolves over the lifetime of
the constraint system, rather than building a new constraint graph at
each solver step, and (2) using the constraint graph to implement a
worklist traversal during simplification, so we only re-simplify those
constraints that might be affected by a choice the solver makes.
This behavior is currently optional with an ugly in-source flag
because while it works, it's a rather painful performance regression
that I don't want to subject everyone to. I'll turn it on for everyone
once it's a win, which should be after either (1) or (2) above is
implemented.
Swift SVN r10924
We still perform path compression for the representative of a type
variable, but the fixed type of a type variable is no longer
compressed: it either doesn't exist or is stored in the
representative. This preserves the equivalence-class structure of type
variables even after they've been bound to fixed types.
Swift SVN r10921
This per-component ranking selects the best partial solution (or at
least minimizes the set of partial solutions) before composing the
results of the partial solutions into set of solutions. This way, we
don't end up creating a huge number of solutions (i.e., all
permutations of the partial solutions) that we'll then have to compare.
27% improvement in type-checking time for the standard library.
Swift SVN r10865
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Using "T" as the contextual type, either for an implicit conversion
(in the coercion case) or as a downcast (for the checked-cast case),
opens up more type-inference opportunities. Most importantly, it
allows coercions such as "1 as UInt32" (important for
<rdar://problem/15283100>). Additionally, it allows one to omit
generic arguments within the type we're casting to.
Some additional cleanup to follow.
Swift SVN r10799
Constraints move between the active and retired lists fairly often, so
use a doubly-linked list to eliminate memory traffic and O(n) copies
of constraint pointers between the lists by using splicing instead.
Swift SVN r10715
Reduces type checking time for the standard library by ~13%, the
number of solver states visited by ~25%, and the number of pointlessly
visited constraints by ~30%. There are only 2175 separable
connected components in the standard library, likely because our
heuristics for picking type variables/constraints to solve bias
against connected components.
Swift SVN r10674
At each solution phase, construct a constraint graph and identify the
smallest connected component. Only solve for the variables in that
connected component, and restrict simplification to the constraints
within that connected component. This reduces the number of
visited-but-not-simplified constraints by ~2x when type-checking the
standard library.
Performance-wise, this is actually a regression (0.25s/8% when parsing
the standard library), because the time spent building the constraint
graph exceeds the time saved by the optimization above.
The hackaround in the standard library is due to
<rdar://problem/15168483>. Essentially, this commit changes the order
in which we visit type variables, causing the type checker to make
some very poor deduction choices.
The point of actually committing this is that it validates the
constraint graph construction and sets the stage for an actual
optimization based on isolating the solving work for the different
components.
Swift SVN r10672
The constraint solver statistics now tell us which of the constraint
systems we are solving were the largest. This lets us look at what the
solver does with that constraint system without piling on the
debugging spew.
Swift SVN r10638
This is one of the last few type checker clients of
PolymorphicFunctionType, where we were relying on opening archetypes
rather than generic parameters.
Swift SVN r9870
This eliminates the need to separately reconstruct all of the
substitutions for the base type of the subscript; our solution already
has all of that information.
Swift SVN r9771
The "conversion" constraint was far too loose, because we don't want
to permit arbitrary conversions on the left-hand side of the
'.'. Conformance constraints aren't correct either, because an
existential that does not conform to itself can still be used on the
left-hand side of a '.', so we introduce a new kind of constraint for
this.
Swift SVN r9630
Rather than jumping through special hoops to deal with operators in
protocols, just open those methods via their interface types (which
are generic function types). This eliminates a number of special cases
for protocol methods.
Swift SVN r9626
Once we've opened method references via the interface type, we then
fold all levels of generic argument specialization into the
DeclRefExpr, rather than using SpecializeExpr. For reference, the call
to x.f in this example:
struct X<T> {
func f<U>(u : U) { }
}
func honk(x: X<Int>) {
x.f("hello")
}
goes from this double-specialized AST:
(specialize_expr implicit type='(u: String) -> ()'
(with U = String)
(dot_syntax_call_expr type='<U> (u: U) -> ()'
(specialize_expr implicit
type='(@inout X<Int>) -> <U> (u: U) -> ()'
(with T = Int)
(declref_expr type='<T> @inout X<T> -> <U> (u: U) -> ()'
decl=t.X.f@t.swift:2:8 specialized=no))
to the cleaner, SpecalizeExpr-free:
(dot_syntax_call_expr type='(u: String) -> ()'
(declref_expr type='(@inout X<Int>) -> (u: String) -> ()'
decl=t.X.f@t.swift:2:8 [with T=Int, U=String]
specialized=no)
which handles substitutions at both levels together. The minor SILGen
tweak
Note that there are numerous other places where we are still generated
SpecializeExprs.
Swift SVN r9614
Rely on opening the GenericFunctionType of a method, rather than its
PolymorphicFunctionType. Alas, constraint application still falls back to
the PolymorphicFunctionType.
Swift SVN r9564
Replace DeclRefExpr's stored ValueDecl* with a ConcreteDeclRef,
allowing it to store the complete set of substitutions applied to
the declaration. Start storing those substitutions (without using them
yet).
Swift SVN r9535
This variant of specialize() uses the requirements list of the generic
function type to form the substitution list, rather than relying on
the polymorphic function type and all-archetypes lists.
Swift SVN r9518
When the type checker sees a reference to a generic non-member
function, open its interface type, which is expressed as a
GenericFunctionType, rather than its PolymorphicFunctionType. This is
a tiny step toward weaning the type checker off archetypes within the
interface.
Swift SVN r9504
