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
- GenProto.cpp for protocols and protocol conformances
- GenExistential.cpp for existential type layout and operations
- GenArchetype.cpp for archetype type layout and operations
Swift SVN r32493
capture list arguments like "[weak self]". The better solution
would be to require all variables to be described with a
SILDebugValue(Addr) and then not describe capture list
arguments (tracked in rdar://21185379).
rdar://problem/22702122
Swift SVN r31963
rdar://22666588
This change removes a comparison and a branch on every virtual call. Before this
change we were generating code for comparing the metadata to figure out if the
incoming instance is an 'exact' cast, and then we checked if the result of the
cast was zero. This is unnecessary because we can simply reuse the result of the
exact metadata comparison. Moreover, we know that the metadata instance can't be
zero because we've emitted a load to that address that did not trap.
%1 = getelementptr inbounds %C4main1X, %C4main1X* %0 ...
%.metadata = load %swift.type*, %swift.type** %1 // Loading %0
%2 = icmp eq %swift.type* %.metadata, bitcast (...)
%3 = icmp ne %C4main1X* %0, null ; <----------- %0 can't be null.
%4 = and i1 %3, %2
br i1 %4, label %5, label %7
Swift SVN r31920
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
The isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
I'm sure this is totally safe, why wouldn't it be?
Fixes <rdar://problem/21095584> Swift: UnsafePointer on tuple works in
debug but compiles crashing binary in release
Swift SVN r29614
When producing TypeInfo for a box, try to reuse instantiations for common type structures:
- any POD type with the same stride and alignment can share a fixed HeapLayout;
- any single-refcounted-pointer type can share a fixed HeapLayout with types that have the same ReferenceCounting;
- dynamically-sized types can share a runtime-based box implementation.
For the runtime implementation, use new to-be-implemented variants of allocBox/deallocBox that will produce polymorphically-projectable boxes using instantiated metadata.
Swift SVN r29612
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
functions to create load/store instructions without alignment.
Fix a couple of places that were unnecessarily using this.
This includes patching up some very suspicious code for generating
"shadow copies" of explosions for debug info that's not using
the existing TypeInfo-based load/store facilities for some
reason; I left the existing pattern in place for now, but it's
probably bogus.
Swift SVN r29459
Share the code that does elementwise coercions, which already behaved correctly, with the code that does struct-to-struct coercions, which still had the overly-conservative constraint. Fixes rdar://problem/21294916.
Swift SVN r29399
We can simultaneously allocate and initialize an opaque existential container's fixed-size buffer the same way, which benefits conversions from generic types to protocol types.
Swift SVN r29371
The type of the self parameter of an @objc_method might be a
BoundGenericClassType or a GenericTypeParamType. In these cases
we have to bind metadata.
For an @objc protocol P, the calling convention for an existential P
would try to pass type metadata in an extra argument, just like it
would for a <T : P> T. However, it is only necessary in the latter
case, because only there we can reflect on T to observe the statically
bound generic type. Fix this with a small hack so that ObjC protocol
methods don't get an extra argument for Self.
This patch alone doesn't enable any new functionality by itself,
because we hit the 'unimplemented dynamic layout' error instead of
crashing.
Swift SVN r29258
functions without a DeclContext. Currently this cannot happen,
but future SILPasses may rewrite functions in a way that it is meaningless
to preserve the function's DeclContext.
Swift SVN r29201
The old SIL-based approach failed to recognize function arguments of
SIL-inlined functions as arguments.
Post-Xcode 7 it would be better to lower this information during SILGen
and emit a debug_value for every function argument so we don't need
to reconstruct them after all the SIL optimizations.
rdar://problem/21109015
Swift SVN r29180
The type of the self parameter of an @objc_method might be a
BoundGenericClassType or a GenericTypeParamType. In these cases
we have to bind metadata.
For an @objc protocol P, the calling convention for an existential P
would try to pass type metadata in an extra argument, just like it
would for a <T : P> T. However, it is only necessary in the latter
case, because only there we can reflect on T to observe the statically
bound generic type. Fix this with a small hack so that ObjC protocol
methods don't get an extra argument for Self.
This patch alone doesn't enable any new functionality by itself,
because we hit the 'unimplemented dynamic layout' error instead of
crashing.
Swift SVN r29136
It's not worth burning more than three registers on a parameter, and doing so causes code size issues for large structs and enums. Make it so that values with more than three explosion members get passed indirectly, just like they get returned indirectly.
This time, modify emitPartialApplyForwarder not to attempt to 'tail' call the original function when indirect arguments get alloca'ed on the stack, which is UB, and don't use "byval", as suggested by John.
Swift SVN r29032
It's not worth burning more than three registers on a parameter, and doing so causes code size issues for large structs and enums. Make it so that values with more than three explosion members get passed indirectly, just like they get returned indirectly.
Swift SVN r29016
There was some duplicated code and we weren't doing a claimAll() on the
input explosion in one of the duplicates.
This partially reverts r28686, but keeping the test and updating it.
Second version of this patch makes the SIL verifier and combiner passes
use the same predicate, fixing assertion failures when casting
metatypes.
Fixes <rdar://problem/21005110>.
Swift SVN r28873
