This will be used in call graph construction so that we can model calls
to deinits that are potentially called as a result of executing
instructions that can end up releasing memory.
This improves support for promoting to and generating
unchecked_ref_cast so we no longer need unchecked_ref_bit_cast, which
will just go away in the next commit.
Swift SVN r32597
_unsafeCastReference allows casting of any references types, regardless
of whether they are references to objects or class existentials. The
implementation is responsible for converting between representations.
_unsafeCastReference provides a dynamic check to ensure that the source
and dest are both actually references. If not, the implementation will
trap at runtime. Generally, the optimizer can prove that the source
and dest are references, and promote this cast to an
unchecked_ref_cast bitcast. There is no dynamic check that the
references types are compatible.
This differs from unsafeDownCast in two ways:
(1) The source and dest types are not statically typed
AnyObjects. Therefore, unsafeCastReference can be used when the
surrounding code dynamically handles both reference and nonreference
types.
(2) The source and dest also need not dynamically conform to AnyObject.
Either side of the cast may be a class existential. The primary
requirement is that the source and dest refer to the same reference
counted object.
Swift SVN r32588
Previously all uses of this instruction used the single element ArrayRef
constructor. The single element ArrayRef constructor does not require any extra
memory. In the case where one does need extra memory, one would need to allocate
the memory for the init_existential_metatype and pass it in. This commit changes
init_existential_metatype to tail allocate the memory for the conformance
pointers and memcpy them in from the array.
Discovered when a SmallVector of protocol conformances resulted in memory
corruption and frustration =--(.
rdar://22302277
Swift SVN r31276
If the compiler can prove that a throwing function actually does not throw it can
replace a try_apply with an "apply [nothrow]". Such an apply_inst calls a function
with an error result but does not have the overhead of checking for the error case.
Currently this flag is not set, yet.
Swift SVN r31151
dealloc_ref [destructor] is the existing behavior. It expects the
reference count to have reached zero and the isDeallocating bit to
be set.
The new [constructor] variant first drops the initial strong
reference.
This allows DI to properly free uninitialized instances in
constructors. Previously this would fail with an assertion if the
runtime was built with debugging enabled.
Progress on <rdar://problem/21991742>.
Swift SVN r31142
Often times one will want to process a BuiltinInst just based off of the
intrinsic or builtin kind. Generally one only wants to process one or
the other and has to introduce variables for the IntrinsicInfo or
BuiltinInfo to a wider scope than one wishes to. These builtins simplify
the processing of such builtins by allowing one to create an if
statement scope around the variable.
if (auto Kind = BI->getBuiltinKind()) {
...
}
if (auto ID = BI->getIntrinsicID()) {
...
}
Swift SVN r30835
I am going to use this functionality while performing refactoring of Projection,
ProjectionTree to make it easier to perform partial dead code elimination and
owned -> guaranteed optimization at the same time.
Swift SVN r30000
The usage in ConstantPropagation required checking if a branch was passed to the
erase action since in Constant Propagation we want to only invalidate
ProgramFlow if possible. I already fixed this part in r29604. In this commit, I
cleaned up the code by adding/using a "PreserveKindBuilder" that a pass can use
to conveniently accumulate invalidations. This part of the change is just a
refactoring.
In the case of SimplifyCFG we always invalidate everything, we do not need to do
any special checking beyond making sure that a non-null value is passed back
from the cast optimizer. From my investigations in the cast optimizer, it
appears that this always occurs currently. But just in case some future code is
added that allows for a nullptr to come back after it has made modifications, I
added code that ensures that we properly set MadeChange if we modify any
instructions. Since this currently can not happen, I can not write a test for it
that is meaningful.
In the case of SILCombine, we do not perform transformations that invalidate the
CFG, so the current method of using SILCombine's RAUW and inst erase hooks
handle the situation correctly.
Swift SVN r29778
We need a SIL level unsafe cast that supports arbitrary usage of
UnsafePointer, generalizes Builtin.reinterpretCast, and has the same
semantics on generic vs. nongeneric code. In other words, we need to
be able to promote the cast of an address type to the cast of an
object type without changing semantics, and that cast needs to support
types that are not layout identical.
This patch introduces an unchecked_bitwise_cast instruction for that
purpose. It is different from unsafe_addr_cast, which has been our
fall-back "unknown" cast in the past. With unchecked_bitwise_cast we
cannot assume layout or RC identity. The cast implies a store and
reload of the value to obtain the low order bytes. I know that
bit_cast is just an abbreviation for bitwise_cast, but we use
"bitcast" throught to imply copying a same sized value. No one could
come up with a better name for copying an objects low bytes via:
@addr = alloca $wideTy
store @addr, $wideTy
load @addr, $narrowTy
Followup patches will optimize unchecked_bitwise_cast into more
semantically useful unchecked casts when enough type information is
present. This way, the optimizer will rarely need to be taught about
the bitwise case.
Swift SVN r29510
Still no implementation yet; we'll need to renovate how boxes work a bit to make them projectable (and renovate SILGen to generate typed boxes for the insn to be useful).
Swift SVN r29490
This reverts commit r29475 because it conflicts with reverting r29474,
and it looks like that commit is breaking the build of the SpriteKit
overlay.
Swift SVN r29481
Still no implementation yet; we'll need to renovate how boxes work a bit to make them projectable (and renovate SILGen to generate typed boxes for the insn to be useful).
Swift SVN r29475
SILGen is used to passing in lowered types without getting their object types specifically, and the object type may not be a legal SIL type for address-only types. Fixes rdar://problem/21408736.
Swift SVN r29436
A somewhat more natural solution would be to replace the
normal successor with an edge to an unreachable block,
but that would require adding blocks during the iteration.
Add a small amount of SIL infrastructure for asking a
pred_iterator exactly which edge out of a terminator it
represents.
Swift SVN r28514
Preparation to fix <rdar://problem/18151694> Add Builtin.checkUnique
to avoid lost Array copies.
This adds the following new builtins:
isUnique : <T> (inout T[?]) -> Int1
isUniqueOrPinned : <T> (inout T[?]) -> Int1
These builtins take an inout object reference and return a
boolean. Passing the reference inout forces the optimizer to preserve
a retain distinct from what’s required to maintain lifetime for any of
the reference's source-level copies, because the called function is
allowed to replace the reference, thereby releasing the referent.
Before this change, the API entry points for uniqueness checking
already took an inout reference. However, after full inlining, it was
possible for two source-level variables that reference the same object
to appear to be the same variable from the optimizer's perspective
because an address to the variable was longer taken at the point of
checking uniqueness. Consequently the optimizer could remove
"redundant" copies which were actually needed to implement
copy-on-write semantics. With a builtin, the variable whose reference
is being checked for uniqueness appears mutable at the level of an
individual SIL instruction.
The kind of reference count checking that Builtin.isUnique performs
depends on the argument type:
- Native object types are directly checked by reading the
strong reference count:
(Builtin.NativeObject, known native class reference)
- Objective-C object types require an additional check that the
dynamic object type uses native swift reference counting:
(Builtin.UnknownObject, unknown class reference, class existential)
- Bridged object types allow the dymanic object type check to be
bypassed based on the pointer encoding:
(Builtin.BridgeObject)
Any of the above types may also be wrapped in an optional. If the
static argument type is optional, then a null check is also performed.
Thus, isUnique only returns true for non-null, native swift object
references with a strong reference count of one.
isUniqueOrPinned has the same semantics as isUnique except that it
also returns true if the object is marked pinned regardless of the
reference count. This allows for simultaneous non-structural
modification of multiple subobjects.
In some cases, the standard library can dynamically determine that it
has a native reference even though the static type is a bridge or
unknown object. Unsafe variants of the builtin are available to allow
the additional pointer bit mask and dynamic class lookup to be
bypassed in these cases:
isUnique_native : <T> (inout T[?]) -> Int1
isUniqueOrPinned_native : <T> (inout T[?]) -> Int1
These builtins perform an implicit cast to NativeObject before
checking uniqueness. There’s no way at SIL level to cast the address
of a reference, so we need to encapsulate this operation as part of
the builtin.
Swift SVN r27887
reference to something of class type. This is required to model
RebindSelfInConstructorExpr correctly to DI, since in the class case,
self.init and super.init *take* a value out of class box so that it
can pass the +1 value without performing an extra retain. Nothing
else in the compiler uninitializes a DI-controlled memory object
like this, so nothing else needs this. DI really doesn't like something
going from initialized to uninitialized.
Yes, I feel super-gross about this and am really unhappy about it. I
may end up reverting this if I can find an alternate solution to this
problem.
Swift SVN r27525
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
We ignore calls to ArraySemantic functions when we hoist uniqueness checks. With
+0 self, this is disrupted by the release that now is in the caller instead of
the callee.
This patch fixes that problem by teaching COWArrayOpts about "guaranteed call
sequences". This is the following pattern:
retain(x)
... nothing that decrements reference counts ...
call f1(@guaranteed_self x)
... nothing that decrements or uses ref counts ...
call f2(@guaranteed_self x)
... nothing that decrements or uses ref counts ...
...
... nothing that decrements or uses ref counts ...
call f$(n-1)(@guaranteed_self x)
... nothing that decrements or uses ref counts ...
call fn(@guaranteed_self x)
... nothing that uses ref counts ...
release(x)
This pattern is created when there are a bunch of guaranteed calls together in a
row (which seems to happen at the "semantic" SIL level). We pattern match the
sequence and then verify that all of the calls are semantic calls. If the
verification succeeds, we can hoist the uniqueness check.
rdar://20340699
Swift SVN r26835
threaded into IRGen; tests to follow when that's done.
I made a preliminary effort to make the inliner do the
right thing with try_apply, but otherwise tried to avoid
touching the optimizer any more than was required by the
removal of ApplyInstBase.
Swift SVN r26747
This includes:
1. Extract instructions which extracts a trivial part of an aggregate that has
one RCIdentity.
2. Instructions which take a pointer out of ARC's control by converting it to a
trivial type. This is safe to do since we can assume that the object that is
convered is alive when the conversion happens. So assuming that we can
conservatively find all RC users, we will have at least one RC user that
post dominates the use (since otherwise we would be touching a dangling
pointer). We leave it to the user of the pass to determine what is safe to do
with this information. Potentially in the future it might make sense to return
this information as well so that a user can use that information directly.
rdar://20305817
Swift SVN r26583
The new base class ApplyInstBase contains APIs that are common for ApplyInst and PartialApplyInst. It allows such optimization passes like generic specializer to treat both instructions in the same way whenever it is possible. Before this change, one had to duplicate and adjust a lot of implementation code in such passes, because ApplyInst and PartialApplyInst were not related to each other in any form.
The existing clients of both classes can continue using the usual APIs. No changes are required. Only new clients, which want to treat ApplyInst and PartialApplyInst in a uniform way, may do so. One of such new clients is the generic specializer, whose adjusted implementation will be submitted in the following commit.
Swift SVN r26581
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
