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
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
1. Change assign to follow SILGen's model for a semantic assignment,
which (in the case of unowned pointers) doesn't require the left
and right hand sides to be the same.
2. Change assign to consume/take the refcount from the LHS, following
SILGen's design (which I completely misunderstood before).
Swift SVN r7787
This was not likely an error-free change. Where you see problems
please correct them. This went through a fairly tedious audit
before committing, but comments might have been changed incorrectly,
not changed at all, etc.
Swift SVN r7631
This is was a very mechanical patch where I basically first renamed SILNodes.def
and then just kept fixing things until everything compiled, so even though it is
large patch I feel ok(ish) with committing it.
If anyone has any concerns/etc, please email me and I will revert in 1 second.
Swift SVN r7604
Because union layout may interleave tag bits with payload data, we need to be able to efficiently inject and remove tag bits from an address-only union in-place. To do this, we'll model address-only union initialization by projecting out the data address (union_data_addr) and storing to it, then overlaying the tag bits (inject_union_addr). To dispatch and project out the data, we'll use a destructive_switch_union_addr instruction that clears any tag bits in-place necessary to give a valid data address.
Swift SVN r7589
The instruction represents constructing a loadable union given a case and the data for that case, which will let us emit union constructor functions in SIL instead of IRGen (rdar://problem/14773182).
Swift SVN r7558
to being a semantic assign. The functional difference here is only
for unowned pointers, where now the conversion from strong to unowned
is implicit in the assign.
The logic behind this is that 'assign' is really part of SILGen, that
is only moved later to make it easier to make it be flow sensitive.
Since it is part of SILGen and will be using some of the type lowering
functionality used by SILGen, we should play by its rules.
No functionality change.
Swift SVN r7507
In designing the runtime model for generic unions with John, we decided we're going to need very different SIL semantics for destructuring address-only unions, so I don't think trying to stretch switch_union to cover all unions makes any sense anymore.
Swift SVN r7225
If this is not an invariant on SIL, but only on the output of SILGen,
I'll add an option to the verifier to only check this after SILGen.
Swift SVN r7068
The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
Have project_existential return $*This instead of $Builtin.OpaquePointer, and have protocol_method do the same for methods of opaque protocols. This makes it easier for passes to reason about the semantics of the projected address, since it's restricted by the semantics of SIL addresses.
Swift SVN r6872
