Like GlobalAddrInst, but for SILGlobalVariables. These would become the same instruction when SILGlobalVariable can replace AST-level global references.
Swift SVN r10510
This will let us control linkage and emit new variables independent of the AST in SILGen. In particular, for lazy global initialization, we need to emit a unique internal once predicate for every top-level pattern binding. Switching everything over is a bit much to reengineer all at once, so for now, it can coexist with the globals map that is already there.
Swift SVN r10509
Ideally this wouldn't be necessary, but the type substitution APIs required by generic specialization and SIL verification currently require a Module* pointer, and it's obnoxious to have to pass it down separately everywhere it's needed. Longer-term the reliance on Modules for type substitution might be able to go away.
Swift SVN r9866
And tweak the verifier to allow 'convert_cc' over a static FunctionRefInst to remain thin. The SILGen part of <rdar://problem/14097136>.
Swift SVN r9556
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
When verifying a SILFunction, walk its CFG, verifying that alloc_stacks and dealloc_stacks balance in stack order, that stack height is consistent coming from all predecessors of a block, and that all alloc_stacks are deallocated prior to returning from a function.
Swift SVN r8985
When we walk a ClassDecl, generate its vtable, first pulling in decls from its ancestor classes, then overlaying overridden or new decls as we discover them.
Swift SVN r8947
These will provide a SIL-level representation of class_method dispatch, mapping from dynamically-dispatched SILDeclRefs to SILFunctions so that devirtualization passes will be able to promote a class_method for a statically-known type to a function_ref without going all the way back to the AST.
Swift SVN r8943
Make ApplyInst and PartialApplyInst directly take substitutions for generic functions instead of trying to stage out substitutions separately. The legacy reasons for doing this are gone.
Swift SVN r8747
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Replace the existing suite of checked cast instructions with:
- unconditional_checked_cast, which performs an unconditional cast that aborts on failure (like the former downcast unconditional); and
- checked_cast_br, which performs a conditional pass and branches on whether the cast succeeds, passing the result to the true branch as an argument.
Both instructions take a CheckedCastKind that discriminates the different casting modes formerly discriminated by instruction type. This eliminates a source of null references in SIL and eliminates null SIL addresses completely.
Swift SVN r8696
This mirrors the behavior of project_existential and simplifies some special cases in SILGen. It unfortunately makes dynamic_lookup sequences a bit noisier because of the need to explicitly cast the projection from DynamicLookup.Self to Builtin.ObjCPointer, but I think this modeling is more solid and will fit better with my planned redesign of archetype_method/protocol_method.
Swift SVN r8572
entire aggregates at once.
This has three worth effects:
- It significantly decreases the amount of SIL required
for these operations.
- It makes it far easier for IR-gen to choose efficient
patterns of destruction, e.g. calling a single entrypoint
or recognizing that it can just use the runtime 'release'
entrypoints.
- It makes it easier to recognize and optimize aggregate
copy/destroy operations.
It does make SROA-like tasks a bit more challenging. The
intent is to give TypeLowering a way to expand these into
their primitive behavior.
Swift SVN r8465
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
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
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
