The reason that this is true is that if the cast is dead, we will delete
it. If it is not dead there must be some other use after the cast that
uses our pointer via the cast. If that is true and there is a release
after that use we will not move the release over the use. On the other
hand if the release is in between the cast and the use it is of course
safe to move the release forward.
Swift SVN r16797
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
When checking for users of an object we need to consider all values
because any use of the object may increase its lifetime.
For example, in the sil code below, instruction %26 increases the lifetime of
object %9. If we remove the retain-release pair then the apply inst may
release %9 and the load would become invalid.
strong_retain %9#0 : $Builtin.ObjectPointer
%24 = apply %19<>()
%26 = load %9#1 : $*Int
strong_release %9#0 : $Builtin.ObjectPointer
return %26 : $Int
This fixes rdar://16233340
Swift SVN r14745
alloc_ref_dynamic allocates an instance of a class type based on the
value in its metatype operand. Start emitting these instructions for
the allocating constructor of a complete object initializer (not yet
tested) and for the allocating constructor synthesized for an imported
Objective-C init method.
Still missing:
- IRGen still does the same thing as alloc_ref right now. That
change will follow.
- There are devirtualization opportunities when we know the value of
the metatype that would turn an alloc_ref_dynamic into an alloc_ref;
I'm not planning to do this optimization.
Swift SVN r14560
that an apply which may decrement ref counts can not decrement a value with
reference semantics if we can prove the value does not alias any of the applies
arguments.
Swift SVN r14120
