Mangling is still a hack, pending a better type AST. Fixed
a bug where arguments passed indirectly were not being destroyed
by the callee (when passed by value). Changed some of the protocol
signatures to use the generic opaque pointer type, making the
types a bit more self-documenting in the IR.
Swift SVN r2274
used in the very narrow case where we were converting from one
protocol type to another (super) protocol type. However, ErasureExpr
now handles this case via its null conformance entries (for the
"trivial" cases), and can cope with general existential types where
some conversions are trivial and others are not.
The IR generation side of this is basically just a hack to inline the
existing super-conversion code into the erasure code. This whole
routine will eventually need to be reworked anyway to deal with
destination types that are protocol-conformance types and with source
types that are archetypes (for generic/existential interactions).
Swift SVN r2213
There are currently two places where you can use a static function defined on a protocol:
on an object with the type of the protocol (discarding the base), and on an archetype in a generic function. The AST for the protocol object case is probably okay;
the AST for the generic case is almost certainly wrong, but that whole area isn't really stable at the moment anyway. The proposal in rdar://problem/11448251 will
add a third way: operators on protocols will be found by overload resolution. (Having static functions on protocols opens up the possibility of metaprotocols,
but I don't think I need to worry about that for the moment.)
Swift SVN r2211
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
a fixed size of 16 bytes. 3 pointers is the magic value in
swift: many, many things are better if we can handle three
pointers efficiently.
Swift SVN r2147
which defeated the optimization which formed "retainThree" tail calls. Restructure
and generalize this optimization to handle the new and old forms. Through
the combination of the two, we now form 19 of them on the stdlib. Before I broke
things, we only formed 14 of them.
Swift SVN r2124
This makes the two phases independently testable, but is also the
right thing to do: previously we'd form swift_retain early enough
that inlining would inline them from previously optimized callees
into callers, and this would block some mid-level optimizations
from doing nice things (because swift_retain isn't no-escape).
It's a small thing, but doing this allows us to eliminate a few
more "and x, 9223372036854775807"'s from the stdlib. We also
end up doing a lot less optimizations because we do them early
instead of only having the optimizations exposed after inlining
deeply.
Swift SVN r2114
don't mod/ref any state to swift code. This allows the general LLVM optimizer to be
*much* more aggressive. For example, on swift.swift, GVN deletes 15% more instructions,
jump threading folds 2.4X more terminators, SCCP removes 3.3X more instructions, and 2
more retain/release pairs are removed by the ARC optimizer.
Swift SVN r2113
