This patch adds powerpc64le Linux support. While the patch also adds
the matching powerpc64 bits, there are endian issues that need to be
sorted out.
The PowerPC LLVM changes for the swift ABI (eg returning three element
non-homogeneous aggregates) are still in the works, but a simple LLVM
fix to allow those aggregates results in swift passing all but 8
test cases.
Getting a superclass, instance extents, and whether a class is native-refcounted are all useful type API. De-underscore these functions and give them a consistent `swift[_objc]_class*` naming scheme.
There was previously no way to detect a type that is nominally
Optional at runtime. The standard library, namely OutputStream, needs
to handle Optionals specially in order to cirumvent conversion to the
Optional's wrapped type. This should be done with conditional
conformance, but until that feature is available, Builtin.isOptional
will serve as a useful crutch.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
<slight revision of yesterday's reverted commit>
The debugAsserts were nicely self-documenting, but generate an obscene
amount of useless SIL code that is inlined everywhere and sticks around
when we compile the stdlib. The old asserts would need to be fixed to
support Optionals but that makes the situation much worse.
Why is it ok to remove the asserts?
_unsafeReferenceCast remains an internal API.
If the src/dest types are not loadable reference types, the cast will
not be promoted to a value bitcast.
The remanining cases will be dynamically checked by swift_dynamicCast.
Swift SVN r32828
Revert "For unsafeReferenceCast rely on static verifier checks."
This reverts commit r32796.
This reverts commit r32795.
They very likely broke a buildbot.
Swift SVN r32813
The debugAsserts were nicely self-documenting, but generate an obscene
amount of useless SIL code that is inlined everywhere and sticks around
when we compile the stdlib. The old asserts would need to be fixed to
support Optionals but that makes the situation much worse.
Why is it ok to remove the asserts?
_unsafeReferenceCast remains an internal API. The invariants are checked
statically whenever the routine is specialized, and dynamically checked
by the runtime cast.
Swift SVN r32795
Generally avoid casting to a raw pointer unless a raw pointer is needed.
Builtin.castReference is now the canonical way to cast reference types.
Canonical generally = better optimizer. In practice this will reduce to
the same SIL since the stdlib code will be optimized.
There are enough unit tests for unsafeDowncast and Builtin.castReference.
I measured no performance regressions.
Swift SVN r32646
_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
This avoids unnecessary address-taking. Instead use the builtin that directly
supports unsafe casts. The optimizer now follows clear rules for
Builtin.reinterpretCast (so it's safe to use) and knows how to optimize it.
Swift SVN r32268
