Unsupported architectures will cause a failure to compile rather than
some kind of runtime trap. In particular, assert() should never be used
in the standard library; we have _sanityCheck for that purpose.
Swift SVN r21373
Replace the true/maybe state that Builtin.canBeClass was returning by a
tri-state (yes, no, maybe) allowing the optimizer to use the definite no
answer. This removes the need of the sizeof check that we had in
isClassOrObjCExistential. It also removes the need to CSE this function since
in most cases we will be able to instantiate canBeClass to yes or no (vs maybe)
at compile time.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
ClassArrayGetter```````,``988.00````,``337.00```,``644.00``,````````191.7%
DeltaBlue``````````````,``2429.00```,``1927.00``,``460.00``,````````23.9%
Dictionary`````````````,``1374.00```,``1231.00``,``129.00``,````````10.9%
Havlak`````````````````,``1079.00```,``911.00```,``124.00``,````````13.7%
Rectangles`````````````,``924.00````,``541.00```,``379.00``,````````70.1%
radar://16823238
Swift SVN r21331
Previously, it was possible to write Unsafe[Mutable]Pointer(x) and have
Swift deduce the pointee type based on context. Since reinterpreting
memory is a fundamentally type-unsafe operation, it's better to be
explicit about conversions from Unsafe[Mutable]Pointer<T> to
Unsafe[Mutable]Pointer<U>. This change is consistent with the move from
reinterpretCast(x) to unsafeBitCast(x, T.self).
Also, we've encoded the operations of explicitly adding or removing
mutability as properties, so that adding mutability can be separated
from wild reinterpretCast'ing, a much more severe form of unsafety.
Swift SVN r21324
The function _isClassOrObjCExistentialAndSizeofAnyObject encapsulates the
"sizeof(x) == sizeof(AnyObject)" check and the call to
swift_isClassOrObjCExistential. The sizeof(x) check cannot be eliminated at the
SIL level and creates extra control flow such that the call to
swift_isClassOrObjCExistential does not dominate. Encapsulating both checks
results in one function call that does dominate allowing us to CSE calls when we
add the attributes inline(late) and effects(readnone).
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
ClassArrayGetter```````,``977.00````,``571.00```,``409.00``,````````72.0%
DeltaBlue``````````````,``2594.00```,``2086.00``,``311.00``,````````14.9%
Rectangles`````````````,``921.00````,``605.00```,``314.00``,````````52.0%
rdar://17961249
Swift SVN r21287
I wish I knew how to code a regression test for this, but sadly I don't.
The only performance differences with magnitude > 7% show up in
-Ounchecked, and most of these look suspiciously like noise due to the
irrelevance of generic string append. The only one I'd be remotely
concerned about is StrToInt, but it doesn't make any sense that it
should have gotten slower, so I think that's noise too.
Ackermann: -14.3%
Fibonacci: 33.3%
ImageProc: 9.0%
Phonebook: -7.1%
QuickSort: 15.6%
StrToInt: -14.3%
Swift SVN r21236
This also reverts the commit "stdlib: Don't check for overflow in subscript accesses to
ContigousArrayBuffer" as removing the overflow check on all unsafe pointers has
the same effect.
Swift SVN r21220
We overflow checked the mulitplication in "a + sizeof(T) * i". This is not
necessary for ContingousArrayBuffer because this overflow check has happened
when we compute the size of the array during allocation of a native swift array
or a NSArray.
benchmark``````````````,``baserun0``,``optrun2``,``delta,``speedup
Memset`````````````````,``1184.00```,``487.00```,``698.00``,````````143.9%
QuickSort``````````````,``1299.00```,``1458.00``,``178.00``,````````-12.2%
SelectionSort``````````,``1027.00```,``814.00```,``213.00``,````````26.2%
StdlibSort`````````````,``1718.00```,``1587.00``,``127.00``,````````8.0%
Walsh``````````````````,``1160.00```,``1076.00``,``86.00```,````````8.1%
XorLoop````````````````,``1248.00```,``884.00```,``369.00``,````````42.0%
The regression in quicksort is noise - i looked at the LLVM IR and the only
thing different in the graph is that we have removed the mulitplication with
overflow check (that is - we should be running faster). Same thing looking at
the assembly.
XorLoop and Memset speed up because we are now able to vectorize those loops.
Swift SVN r21218
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
This function mixes the bits in the hash value, which improves Dictionary
performance for keys with bad hashes.
PrecommitBenchmark changes with greater than 7% difference:
``````````Dictionary2`,```1456.00`,```1508.00`,```1502.00`,````624.00`,````607.00`,````592.00`,`864.00`,``145.9%
``````````Dictionary3`,```1379.00`,```1439.00`,```1408.00`,````585.00`,````567.00`,````552.00`,`827.00`,``149.8%
````````````Histogram`,````850.00`,````849.00`,````851.00`,```1053.00`,```1049.00`,```1048.00`,`199.00`,``-19.0%
````````````````Prims`,```1999.00`,```2005.00`,```2018.00`,```1734.00`,```1689.00`,```1701.00`,`310.00`,```18.4%
``````````StrSplitter`,```2365.00`,```2334.00`,```2316.00`,```1979.00`,```1997.00`,```2000.00`,`337.00`,```17.0%
```````````````TwoSum`,```1551.00`,```1568.00`,```1556.00`,```1771.00`,```1741.00`,```1716.00`,`165.00`,```-9.6%
Regressions are in benchmarks that use `Int` as dictionary key: we are just
doing more work than previously (hashing an `Int` was an identity function).
rdar://17962402
Swift SVN r21142
The test harness now can recover after test crashes, allowing:
- check for crashes themselves (without reporting them to the Python lit driver,
which is about 10x slower -- even if CrashTracer is disabled);
- recover from unexpected test crashes and run the rest of the tests;
- this lays the groundwork for assertions that end the test execution, but
allow the rest of the tests to run (rdar://17906801).
Note that we don't spawn a fresh process for every test. We create a child
process and reuse it until it crashes.
Swift SVN r21090
