This is a type that has ownership of a reference while allowing access to the
spare bits inside the pointer, but which can also safely hold an ObjC tagged pointer
reference (with no spare bits of course). It additionally blesses one
Foundation-coordinated bit with the meaning of "has swift refcounting" in order
to get a faster short-circuit to native refcounting. It supports the following
builtin operations:
- Builtin.castToBridgeObject<T>(ref: T, bits: Builtin.Word) ->
Builtin.BridgeObject
Creates a BridgeObject that contains the bitwise-OR of the bit patterns of
"ref" and "bits". It is the user's responsibility to ensure "bits" doesn't
interfere with the reference identity of the resulting value. In other words,
it is undefined behavior unless:
castReferenceFromBridgeObject(castToBridgeObject(ref, bits)) === ref
This means "bits" must be zero if "ref" is a tagged pointer. If "ref" is a real
object pointer, "bits" must not have any non-spare bits set (unless they're
already set in the pointer value). The native discriminator bit may only be set
if the object is Swift-refcounted.
- Builtin.castReferenceFromBridgeObject<T>(bo: Builtin.BridgeObject) -> T
Extracts the reference from a BridgeObject.
- Builtin.castBitPatternFromBridgeObject(bo: Builtin.BridgeObject) -> Builtin.Word
Presents the bit pattern of a BridgeObject as a Word.
BridgeObject's bits are set up as follows on the various platforms:
i386, armv7:
No ObjC tagged pointers
Swift native refcounting flag bit: 0x0000_0001
Other available spare bits: 0x0000_0002
x86_64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0001
Swift native refcounting flag bit: 0x0000_0000_0000_0002
Other available spare bits: 0x7F00_0000_0000_0004
arm64:
Reserved for ObjC tagged pointers: 0x8000_0000_0000_0000
Swift native refcounting flag bit: 0x4000_0000_0000_0000
Other available spare bits: 0x3F00_0000_0000_0007
TODO: BridgeObject doesn't present any extra inhabitants. It ought to at least provide null as an extra inhabitant for Optional.
Swift SVN r22880
This includes:
1. Teaching SwiftAA that swift_fixLifetime does not affect loads, stores of pointers.
2. Teaching SwiftARCExpand to remove swift_fixLifetime.
3. Teaching SwiftARCOpts that it can move retains but not releases over
swift_fixLifetime.
At -O I get the following % speedups > 10%.
InsertionSort:|%29.73
ImageProc:|||||%23.97
RC4:|||||||||||%19.46
PrimeNum|||||||%18.10
Ary||||||||||||%14.09
Ary2|||||||||||%13.16
<rdar://problem/18685662>
Swift SVN r22814
We can remove objc_retain/releases just like swift ones.
Results -O where SU = minbefore/minafter (10 samples):
TEST`````````````````MIN``MAX``MEAN`SD```MED``MIN``MAX``MEAN`SD```MED````SU
ClassArrayGetter`````1931`1943`1938`4````1940`1143`1158`1150`5````1153```1.68
DeltaBlue````````````3434`3450`3439`4````3441`2906`2932`2913`7````2911```1.18
Dictionary```````````5616`5933`5755`112``5748`5291`5713`5515`140``5563```1.06
PopFrontArray````````103``109``104``1````104``96```99```96```1````96`````1.07
PopFrontArrayGeneric`102``106``103``1````103``95```98```96```1````96`````1.07
PrimeNum`````````````4098`7552`5953`1164`6319`4496`8653`6336`1210`6639```0.91
QuickSort````````````6380`6415`6396`11```6398`6071`6115`6086`13```6082```1.05
Rectangles```````````2277`2377`2322`31```2320`1636`1682`1657`12```1655```1.39
StrCat```````````````2811`2849`2825`12```2822`2487`2516`2501`12```2505```1.13
StringWalk```````````5784`5797`5790`4````5790`6124`6137`6129`4````6127```0.94
Swift SVN r22695
Teach LLVMARCOpts about swift_unknownRetain and that we can move retains accross
objc_retains.
This recovers the performance we lost (see rdar below) due to making retain
sinking more aggressive.
ClassArrayGetter```````,``581.00````,``488.00````,``92.00```,````````18.9%
Rectangles`````````````,``618.00````,``552.00````,``71.00```,````````13.0%
rdar://18337069
Swift SVN r21999
