We can't bitcast an i64 into an i8*, we have to do an int to pointer
cast instead.
This exposes a new issue, where dynamic casts do not support casting
from Optional<A> to A -- tracked in <rdar://problem/23122310>.
Fixes <rdar://problem/23055035>.
Swift SVN r32704
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
And they're not even guaranteed to be casts to ObjC classes. They might be
Swift subclasses of ObjC classes.
This fixes a type-safety hole where, e.g. a generic cast from NSPredicate
to NSDate was allowed because we were checking against NSObject.
rdar://problem/22242369
Swift SVN r31153
emitScalarExistentialDowncast() would return an explosion consisting
of the original input value, followed by witness tables returned by
calling emitExistentialScalarCastFn().
The result of this explosion was then tested by comparing the first
element against NULL, which is wrong, since the first element was
set to the input value unconditionally.
Address this by changing the dynamic cast functions to take the value
as the first argument, and return it as the first element of the
return tuple. The value is not used directly, only set to NULL if the
cast fails. This makes the NULL check in visitCheckedCastBranchInst()
work as intended.
Note that now the result of the cast becomes a different LLVM value
than the input. With the dynamic cast function inlined, this should
not be an issue, since this is already the case for dynamic class cast.
There are also perhaps too many bitcast instructions generated now.
This could be cleaned up.
Fixes <rdar://problem/20920874>.
Swift SVN r28712
All llvm::Functions created during IRGen will have target-cpu and target-features
attributes if they are non-null.
Update testing cases to expect the attribute in function definition.
Add testing case function-target-features.swift to verify target-cpu and
target-features.
rdar://20772331
Swift SVN r28186
Fixes rdar://problem/20583365, and incidentally gets test/Interpreter/layout_reabstraction.swift to work without ObjC interop as well.
Swift SVN r27557
This is needed to support inline caching of self.dynamicType.foo().
Fixes <rdar://problem/19888836> Swift compiler segmentation fault during static analysis
Swift SVN r25686
They don't need one, and nobody really conforms to the AnyObject sham protocol at runtime. Fixes rdar://problem/19624697, though there's going to be a similiar problem with metatype-to-AnyObject casts that needs fixing as well.
Swift SVN r24802
The optimizer could eliminate these but isn't there yet. These instructions are valid nonetheless and should be emittable. Fixes rdar://problem/18934125.
Swift SVN r23269
These always fail, and it doesn't make sense to inline this check into the cast site, so provide additional runtime functions for metatype-to-objc-existential casts.
Swift SVN r23237
The code path here is mostly the same as the class cast case--we have to test the ObjC class (if it is a class) against any ObjC protocols, then look up conformances for the native protocols.
Swift SVN r23184
- A spot fix in SILGen for reabstracting the result of a downcast, which fixes checked casts to function types.
- Associate the layout information in type metadata records with the most abstract representation of the type. This is the correct thing to do in cases where we need the metadata as a tag for an opaque value--if we store a value in an Any, or pass it as an unconstrained generic parameter, we must maximally reabstract it. This fixes the value semantics of existentials containing trivial metatypes.
- To ensure that we get runtime layout of structs and enums correct when they contain reabstractable types, introduce a "metadata for layout" concept, which doesn't need to describe the canonical metadata for the type, but only needs to describe a type with equivalent layout and value semantics. This is a correctness fix that allows us to correctly lay out generic types containing dependent tuples and functions, and although we don't really take advantage of it here, it's also a potential runtime performance win down the road, because we could potentially produce direct metadata for a primitive type that's layout-equivalent with a runtime-instantiated type. To aid in type safety here, push SILType deeper into IRGen in places where we potentially care about specific representations of types.
- Finally, fix an inconsistency between the runtime and IRGen's concept of what spare bits unmanaged references and thick metatypes have.
Together, these fixes address rdar://problem/16406907, rdar://problem/17822208, rdar://problem/18189508, and likely many other related issues, and also fixes crash suite cases 012 and 024.
Swift SVN r21963
unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
