The deallocating parameter convention is a new convention put on a
non-trivial parameter if the caller function guarantees to the callee
that the parameter has the deallocating bit set in its object header.
This means that retains and releases do not need to be emitted on these
parameters even though they are non-trivial. This helps to solve a bug
in +0 self and makes it trivial for the optimizer to perform
optimizations based on this property.
It is not emitted yet by SILGen and will only be put on the self
argument of Deallocator functions.
Swift SVN r26179
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
Deferring to emitRValue doesn't work for inout parameters. Factor out the code for shuffling arguments in TupleShuffleExprs so we can reuse for ScalarToTuple transformations. Building what amounts to a fake TupleShuffle out of a ScalarToTuple isn't the most elegant solution, but I think it's the lowest-risk approach for the short term. Fixes rdar://problem/19814841.
Swift SVN r25290
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
the call instead of during the formal evaluation of the argument.
This is the last major chunk of the semantic changes proposed
in the accessors document. It has two purposes, both related
to the fact that it shortens the duration of the formal access.
First, the change isolates later evaluations (as long as they
precede the call) from the formal access, preventing them from
spuriously seeing unspecified behavior. For example::
foo(&array[0], bar(array))
Here the value passed to bar is a proper copy of 'array',
and if bar() decides to stash it aside, any modifications
to 'array[0]' made by foo() will not spontaneously appear
in the copy. (In contrast, if something caused a copy of
'array' during foo()'s execution, that copy would violate
our formal access rules and would therefore be allowed to
have an arbitrary value at index 0.)
Second, when a mutating access uses a pinning addressor, the
change limits the amount of arbitrary code that falls between
the pin and unpin. For example::
array[0] += countNodes(subtree)
Previously, we would begin the access to array[0] before the
call to countNodes(). To eliminate the pin and unpin, the
optimizer would have needed to prove that countNodes didn't
access the same array. With this change, the call is evaluated
first, and the access instead begins immediately before the call
to +=. Since that operator is easily inlined, it becomes
straightforward to eliminate the pin/unpin.
A number of other changes got bundled up with this in ways that
are hard to tease apart. In particular:
- RValueSource is now ArgumentSource and can now store LValues.
- It is now illegal to use emitRValue to emit an l-value.
- Call argument emission is now smart enough to emit tuple
shuffles itself, applying abstraction patterns in reverse
through the shuffle. It also evaluates varargs elements
directly into the array.
- AllowPlusZero has been split in two. AllowImmediatePlusZero
is useful when you are going to immediately consume the value;
this is good enough to avoid copies/retains when reading a 'var'.
AllowGuaranteedPlusZero is useful when you need a stronger
guarantee, e.g. when arbitrary code might intervene between
evaluation and use; it's still good enough to avoid copies
from a 'let'. The upshot is that we're now a lot smarter
about generally avoiding retains on lets, but we've also
gotten properly paranoid about calling non-mutating methods
on vars.
(Note that you can't necessarily avoid a copy when passing
something in a var to an @in_guaranteed parameter! You
first have to prove that nothing can assign to the var during
the call. That should be easy as long as the var hasn't
escaped, but that does need to be proven first, so we can't
do it in SILGen.)
Swift SVN r24709
a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
Permit non-Ordinary accesses on references to functions,
with the semantics of devirtualizing the call if the
function is a class member. This is important for
constructing direct call to addressors from synthesized
materializeForSet accessors: for one, it's more
performant, and for another, addressors do not currently
appear in v-tables.
Synthesize trivial accessors for addressed class members.
We weren't doing this at all before, and I'm still not
sure we're doing it right in all cases. This is a mess.
Assorted other fixes. The new addressor kinds seem
to work now.
Swift SVN r24393
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
use a thin function type.
We still need thin-function-to-RawPointer conversions
for generic code, but that's fixable with some sort of
partial_apply_thin_recoverable instruction.
Swift SVN r24364
optional callback; retrofit existing implementations.
There's a lot of unpleasant traffic in raw pointers here
which I'm going to try to clean up.
Swift SVN r24123
NFC for now, but I've also added the infrastructure to allow
"early emission", i.e. emission directly from the original
RValueSource, which can be useful either as an optimization
(e.g. for Builtin.initialize) or a requirement for particularly
hacky SIL intrinsics should we need them (and I'm thinking of
needing one).
Swift SVN r23953
isn't used yet, but will be for modeling the self argument passed to an
address-only witness implementation. NFC since all this code is dead :-)
Swift SVN r23857
Using the intrinsics is obnoxious because I needed them
to return Builtin.NativeObject?, but there's no reasonable
way to safely generate optional types from Builtins.cpp.
Ugh.
Dave and I also decided that there's no need for
swift_tryPin to allow a null object.
Swift SVN r23824
It's not always correct to map a Swift Bool back to ObjCBool in C land, since Bool could have originally been a proper _Bool. Pass the clang::Decl down to type lowering so we can recognize this. We still don't have a great solution for block types, because there's no decl to refer to, and Swift's user-level type system erases the distinction between void(^)(_Bool) and void(^)(BOOL). However, this is enough to let us start using C APIs that traffic in _Bool.
Swift SVN r23546
Before this patch there was no dependence visible to the optimizer between a
open_existential and the witness_method allowing the optimizer to reorder the
two instruction. The dependence was implicit in the opened archetype but this
is not a concept model by the SIL optimizer.
%2 = open_existential %0 : $*FooProto to $*@opened("...") FooProto
%3 = witness_method $@opened("...") FooProto,
#FooProto.bar!1 : $@cc(...)
%4 = apply %3<...>(%2)
This patch changes the SIL representation such that witness_methods on opened
archetypes take the open_existential (or the producer of the opened existential)
as an operand preventing the optimizer from reordering them.
%2 = open_existential %0 : $*FooProto to $*@opened("...") FooProto
%3 = witness_method $@opened("...") FooProto,
#FooProto.bar!1,
%2 : $*@opened("...") FooProto : $@cc(...)
%4 = apply %3<...>(%2)
rdar://18984526
Swift SVN r23438
Though the value may be statically known in some cases, that isn't good enough to do what we try to do with this information. In particular, if we invoke a class method on a MetatypeConversion, we want to dispatch to the method of the original metatype, not statically call the method of the converted type, which is what is evident in the AST. Fixes rdar://problem/18877135.
Swift SVN r23277
Most of the parts were already here. We mishandled a few edge cases in RValueEmitter because of MemberRefExpr/ApplyExpr confusion at the Sema level, and we artifically asserted that we didn't support this. Removing the assertion and wiring up the existing thunking infrastructure made this just fall out. Fixes rdar://problem/18763738.
Swift SVN r22944
This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
And in IRGen, fix up pointer cast codegen to work with types that explode to single scalars while being stored in named structs. Fixes rdar://problem/18604262
Swift SVN r22671
Use open_existential/witness_method instead of project_existential/protocol_method for property accessor lookups to, eliminating the remaining uses of protocol_method.
Swift SVN r22443
This simplifies the code generation path for existential methods by allowing it to shared more code with the generic case, (It'll be even simpler when Sema opens the existentials for SILGen...) turning protocol_method lookups into open_existential + witness_method sequences. In this patch, we handle normal generic method lookups, but property accesses still go through protocol_method.
Swift SVN r22437
This fixes bugs when we call the result of generic methods that return functions; we were advancing through orig types of the signature but not formal ones, causing us to fall out of sync when we exhausted curry levels of the original function and started calling function-typed results. Fixes rdar://problem/18143223 and rdar://problem/18495979, maybe others too.
Swift SVN r22418
"self" needs to be materialized in these cases. We were handling methods correctly, but not property accesses. Fixes rdar://problem/18454204.
Swift SVN r22309
semantically valid way.
Previously, this decision algorithm was repeated in a
bunch of different places, and it was usually expressed
in terms of whether the decl declared any accessor
functions. There are, however, multiple reasons why a
decl might provide accessor functions that don't require
it to be accessed through them; for example, we
generate trivial accessors for a stored property that
satisfies a protocol requirement, but non-protocol
uses of the property do not need to use them.
As part of this, and in preparation for allowing
get/mutableAddressor combinations, I've gone ahead and
made l-value emission use-sensitive. This happens to
also optimize loads from observing properties backed
by storage.
rdar://18465527
Swift SVN r22298
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
This avoids a pointless copy every time an array literal is written, and will let us retire the horrible "alloc_array" instruction and globs of broken IRGen code. Implements rdar://problem/16386862, and probably fixes a bunch of bugs related to alloc_array brokenness.
Swift SVN r22289
Addressors now appear to pass a simple smoke-test; in
order to allow some parallel developement, I'll be
committing actual SILGen tests for this later and
separately.
Swift SVN r22243
The metatype is associated with the formal AST type of the value, not whatever lowered SIL type we happen to have lying around. Adjust the SIL verifier to check that value_metatype instructions produce a metatype for which the instance is a potential lowering rather than by exact type match. This lets us take the metatype of metatypes (and incidentally, of functions, and of tuples thereof), fixing rdar://problem/17242770.
Swift SVN r22202
accessors on non-dynamic storage.
This allows us to take advantage of dynamic knowledge
that a property is implemented as stored in order to
gain direct access to it instead of copying into a
temporary. When a class or protocol-member property
is expensive to copy, and particularly when it's of
copy-on-write type, such direct accesses can massively
improve the performance of a program.
We are currently only able to apply this when the
property is implemented purely as stored. A willSet
observer inherently blocks the optimization, but we
should be able to make it work even for properties
with didSet observers. This could be done by returning
an arbitrary callback from materializeForSet instead
of returning a flag indicating whether to call the
setter.
rdar://17416120
Swift SVN r22122
