for func decls that capture globals defined in the current file. For example, for:
var x : Int
func foo() {
print(x)
}
x = 15
We now silgen to:
sil internal @top_level_code : $() -> () {
bb0:
%0 = global_addr #x : $*Int64 // user: %1
%1 = mark_uninitialized %0 : $*Int64 // users: %7, %2
mark_function_escape %1 : $*Int64
// function_ref swift.Int64._convertFromBuiltinIntegerLiteral (swift.Int64.metatype)(val : Builtin.Int128) -> swift.Int64
%3 = function_ref @_TSi33_convertFromBuiltinIntegerLiteralfMSiFT3valBi128__Si : $[thin] ((val : Builtin.Int128), Int64.metatype) -> Int64 // user: %6
%4 = metatype $Int64.metatype // user: %6
%5 = integer_literal $Builtin.Int128, 15 // user: %6
%6 = apply [transparent] %3(%5, %4) : $[thin] ((val : Builtin.Int128), Int64.metatype) -> Int64 // user: %7
assign %6 to %1 : $*Int64
%8 = tuple () // user: %9
return %8 : $()
}
which will allow definite initialization to diagnose the error.
Note that we don't currently handle uses in constructors, like:
class frank {
constructor() {
print(x)
}
}
... because the capture list is only stored for FuncDecls, not for AbstractFunction's. It should be hoisted up at some point.
Swift SVN r8188
When enabled, this causes references to global variables in the
top_level_code function to be emitted as:
%0 = global_addr #x : $*Int64
%1 = mark_uninitialized %0 : $*Int64
where all local uses of "x" use the %1 value. This representation will
allow the definite initialization pass to know that "x" must be forced
to be initialized before the function returns or the value escapes (which
we don't have a representation for yet).
Swift SVN r8147
binding decls for global variables, enter the global_addr into the
VarLocs mapping so that the global_addrs are CSE'd in the generated
SIL code. For now, this simply reduces the size of the generated
SIL (by reducing some common subexpressions) with no other
functionality change.
Swift SVN r8146
If a method comes from Clang, SILGen (correctly) asserts that we don't try to emit a reference to a native Swift entry point for it. Check for and handle this case in the lazy curry thunking logic.
Swift SVN r8128
Instead of eagerly emitting currying thunks as external symbols, emit them as needed and give them hidden ODR linkage. Partial function/method applications are probably a minority of usages, so this should reduce code volume overall. Also, for ObjC classes from the framework and for protocol methods, I don't think we want to eagerly emit thunks.
Swift SVN r8123
Lazily-generated currying thunks will require the same IR-level linkonce_odr linkage as clang thunks currently do, so generalize the name of the existing SIL-level linkage specifier 'clang_thunk'.
Swift SVN r8122
ObjC methods are already tagged with a special calling convention and have special IRGen handling to keep the _cmd argument abstracted away from SIL. We can use the CC to also abstract away the detail that Swift methods pass 'self' last but ObjC methods pass 'self' first. This eliminates a weird special case from SIL's perspective, and also means that 'partial_apply' can work on objc methods correctly without becoming significantly more complex.
Swift SVN r8091
In SILGenApply, if we have a partially-applied invocation of a class method, make a call to a currying thunk instead of trying to perform dynamic dispatch in-line. Emit the class dynamic dispatch instead as part of the currying thunk itself, and close over the dynamic method pointer as part of the curried closure context.
Swift SVN r8076
If an OpaqueValueExpr is only used in one place, mark it as such. SIL
generation will then elide the retain/release pair associated with
each reference to the opaque value, instead consuming the value at the
point of use.
Swift SVN r8072
Introduce a proper cleanup for the Optional<T> value created by
non-forced dynamic member lookups.
Additionally, properly manage each reference to an OpaqueValue within
an expression, and release the value when the RAII object goes out of
scope. This is the conservative approach to be optimized soon.
Swift SVN r8071
Among other things this enables mangled names for tuples.
This adds a pointer to the DeclContext to SILFunction and which is used
to provide the necessary context to the Mangler.
Fixes rdar://problem/14808764 and rdar://problem/14813658.
Swift SVN r8070
The dynamic_method_br instruction branches depending on whether a
particular object can accept a given message, as determined at
runtime. If the object can accept the message, it branches to the
first basic block, providing the uncurried method as the BB
argument. If the object cannot accept the message, it branches to the
second basic block. Either way, the result is packaged up into an
optional type and passed along to the continuation block, which
provides the optional result.
Note that this instruction is restricted to lookup of Objective-C
methods.
Documentation and IR generation (via -respondsToSelector) to
follow. Review greatly appreciated!
Swift SVN r8065
SILGen learned how to forward archetypes for generic class constructors, and we can reuse this knowledge to finally implement curry thunks for generic functions.
Generic methods still pose a problem because we can't return a value of polymorphic type, so we'd need to hoist polymorphic parameters to the outermost uncurry level during SIL function type canonicalization even at uncurry level zero.
Swift SVN r8054
These helper expressions will eventually be used by SILGen to help
package up the optional values. I expect that we'll eventually have
library builtins for this, so consider this a stop-gap until those
appear.
As part of this, make OpaqueValueExpr a bit more usable: it can now
persist in the AST as a placeholder, but its uses must be within AST
subtrees of some specific introduction point (similarly to how Clang's
OpaqueValueExpr works).
Swift SVN r8051
ConstructorDecl::getBody() and DestructorDecl::getBody() return 'BraceStmt *'.
After changing the AST representation for functions, FuncDecl::getBody() will
return 'BraceStmt *' and FuncDecl::getFuncExpr() will be gone.
Swift SVN r8050
Struct instance methods don't need to capture any special dynamic dispatch behavior, so they can use the same codegen path as standalone curried functions. Fixes <rdar://problem/14687373>.
Swift SVN r8049
global variables used by functions in the capture list as well.
SILGen and other things that don't care about these (i.e., all
current current clients) filter the list to get what they want.
This is needed for future definite init improvements, and unblocked
by Doug's patch in r8039 (thanks! :)
No functionality change.
Swift SVN r8045
The dynamic_method instruction handles method lookup on an existential
of type DynamicLookup based on the selector of an [objc] method of a
class or protocol. It is only introduced in the narrow case where we
are forcing a use of the method with '!', e.g.,
class X {
func [objc] f() { println("Dynamic lookup") }
}
var x : DynamicLookup = X()
x.f!()
Swift SVN r8037
Also, change the location of "looping back to head" branch to point to the closing brace of the body, which is a more natural source location than the beginning of the enclosing loop statement.
Swift SVN r7989
move the corresponding functionality into SILGen.
I've switched around 'assign' so that it's no longer a
semantic assignment --- that is, so that it expects a properly
lowered value as its operand, not an r-value of the semantic
type. This actually simplifies quite a lot of code and removes
some ugly special-casing from MemoryPromotion.
Swift SVN r7942
