when an object is passed to unknownRetain and retain, the unknownRetain
can be strength reduced to retain. same for unknownRelease and release.
Swift SVN r32087
some of the ARC entry points. rdar://22724641. After this commit,
swift_retain_noresult will be completely replaced by swift_retain.
LLVMARCOpts pass is modified NOT to rewrite swift_retain to
swift_retain_noresult which forward no reference.
Swift SVN r32082
I asked that the patches were split up so I could do post commit review.
This reverts commit r32059.
This reverts commit r32058.
This reverts commit r32056.
This reverts commit r32055.
Swift SVN r32060
to remove reference forwarding for some of the ARC entry points. rdar://22724641. After this
commit, swift_retain_noresult will be completely replaced by swift_retain and LLVMARCOpts.cpp
will no longer canonicalize swift_retain to swift_retain_noresult as now swift_retain returns no
reference.
Swift SVN r32058
We are taking advantage of the fact that we can always safely move a retain
earlier in the program and a release later in the program. Given this
information, in every BB, we merge together all retains into the first retain
(creating a retain_n) and all releases into the last release in that BB
(creating a release_n).
rdar://21803771
Swift SVN r30261
This pass does things similar to LLVMARCContract so it makes sense to use the
same naming schema.
Also I am going to be implementing some contracting optimziations here later
today.
Swift SVN r30203
We were never generating it and are going to transition all of the stdlib data
structures to single pointer representations.
rdar://21665665
Swift SVN r30174
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