Tool selection is primarily done by checking the executable (= symlink) name.
But sometimes (e.g. if the tool symlink is not there) it's useful to have an option for selecting the tool.
The selection option (e.g. -sil-opt) must be the first argument of swift-frontend.
In low level LLVMARCOptimizer, during canonicalization we don't rauw the result of RT_Retain with its arg similarly to RT_ObjCRetain and RT_BridgeRetain.
And during performLocalReleaseMotion, we assert that we have canonicalized RT_Retain.
In a release compiler, if we optimize such an RT_Retain with a RT_Release, then this can result in a compiler crash
Similarly not rauw'ing, can cause a crash due to performLocalRetainMotion
Fixes rdar://79238115
We used to represent these just as normal LLVM functions, e.x.:
declare objc_object* @objc_retain(objc_object*)
declare void @objc_release(objc_object*)
Recently, special objc intrinsics were added to LLVM. This pass updates these
small (old) passes to use the new intrinsics.
This turned out to not be too difficult since we never create these
instructions. We only analyze them, move them, and delete them.
rdar://47852297
These functions don't accept local variable heap memory, although the names make it sound like they work on anything. When you try, they mistakenly identify such things as ObjC objects, call through to the equivalent objc_* function, and crash confusingly. This adds Object to the name of each one to make it more clear what they accept.
rdar://problem/37285743
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
This prevents the linker from trying to emit relative relocations to locally-defined public symbols into dynamic libraries, which gives ld.so heartache.
This lets us remove `swift_fixLifetime` as a real runtime entry point. Also, avoid generating the marker at all if the LLVM ARC optimizer won't be run, as in -Onone or -disable-llvm-arc-optimizer mode.
Now that one can not use analysis groups anymore on LLVM, we were given two
choices. Reinsert that dynamicism so we could via opt -load add in analyses /or/
just create our own version of opt. I decided to go with the later since it
enables us to simulate how IRGen sets up the LLVM pass pipeline exactly,
something we were unable to do before.
This also sets us up for whenever we need to respond to the new pass manager.
Swift SVN r32808
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 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 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
I introduced a function swift_keepAlive2() which has a different signature from
swift_keepAlive() until I can verify that the stdlib is using the new
infrastructure.
The difference in signature is that swift_keepAlive2 takes just a pointer while
swift_keepAlive also takes a metadata value that is not necessary for our
purposes anymore.
Swift SVN r21718
OptimizeARC does not only contain an optimize arc pass: the library also
includes aa. What this really is a repository of the extra passes and
infrastructure that we inject into LLVM. Thus LLVMPasses is a more descriptive
name. It also matches SILPasses.
I also taught lit how to use the new llvm-opt driver for running swift llvm
passes through opt without having to remember how to setup the dynamic swift
llvm pass dylib. You can use this in lit tests by using the substitution
%llvm-opt.
Swift SVN r21654
