When an integer type T is used as an Index, there are always
bounds---more restrictive than the full range of T---against which we're
not able to check. Overflows are not useful indicators of precondition
violations in this context. Therefore, use masked arithmetic for
RandomAccessIndex conformance.
Performance changes of magnitude >= 5% are below. Someone might want to
investigate why Fibonacci got 21% faster in -Ounchecked, since nothing
in this change should have removed checks from that build. (That test
does seem particularly sensitive; see also <rdar://problem/17815767>
Adding three overloads to stdlib slows Fibonacci by 18-19%)
Fixes <rdar://problem/17780469> Integer ranges shouldn't use overflowing adds
====================`PrecommitBench_O`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
````Ackermann`|``1428.00`|``1466.00`|`1661.00`|`1657.00`|`229.00`|``-13.8%`
`````ForLoops`|``2021.00`|``1986.00`|`1249.00`|`1255.00`|`737.00`|```59.0%`
`````````Hash`|``1038.00`|```979.00`|``898.00`|``922.00`|``81.00`|````9.0%`
`````````Life`|````63.00`|````63.00`|```60.00`|```61.00`|```3.00`|````5.0%`
```````Memset`|````55.00`|````54.00`|```42.00`|```42.00`|``12.00`|```28.6%`
``MonteCarloE`|``1243.00`|``1265.00`|``885.00`|``880.00`|`363.00`|```41.3%`
`MonteCarloPi`|```994.00`|``1004.00`|``613.00`|``605.00`|`389.00`|```64.3%`
````````NBody`|````45.00`|````45.00`|```42.00`|```43.00`|```3.00`|````7.1%`
````QuickSort`|```105.00`|```103.00`|```83.00`|```83.00`|``20.00`|```24.1%`
````R17315246`|``1080.00`|``1080.00`|``805.00`|``808.00`|`275.00`|```34.2%`
``````SmallPT`|``1008.00`|``1007.00`|``789.00`|``795.00`|`218.00`|```27.6%`
````````Walsh`|```136.00`|```136.00`|``129.00`|``130.00`|```7.00`|````5.4%`
====================`PrecommitBench_Ounchecked`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
``Dictionary3`|``1060.00`|``1039.00`|``982.00`|`1029.00`|``57.00`|````5.8%`
````Fibonacci`|```842.00`|```848.00`|``694.00`|``694.00`|`148.00`|```21.3%`
```StringWalk`|```945.00`|```924.00`|``989.00`|``995.00`|``65.00`|```-6.6%`
====================`PrecommitBench_Onone`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
`EditDistance`|``2086.00`|``1981.00`|`1492.00`|`1622.00`|`489.00`|```32.8%`
`````````Life`|``1256.00`|``1216.00`|`1110.00`|`1142.00`|`106.00`|````9.5%`
```````MatMul`|``1210.00`|``1245.00`|``705.00`|``705.00`|`505.00`|```71.6%`
````R17315246`|```205.00`|```209.00`|``195.00`|``200.00`|``10.00`|````5.1%`
Swift SVN r20576
Fixes <rdar://problem/17797711>
This is rather a kluge because of two other problems. Having these
fixed would allow a cleaner solution:
<rdar://problem/17815538> synthesize an allZeros static var for
BitwiseOperationsType conformance of imported NS_OPTIONS
<rdar://problem/17815767> Adding three overloads to stdlib slows
Fibonacci by 18-19%
Swift SVN r20563
to emit fixit's when we rename something, e.g.:
t.swift:6:9: error: 'float' has been renamed to Float
var y : float
^~~~~
Float
Adopt this in the stdlib.
Swift SVN r20549
is performed according to the deterministic Unicode collation algorithm,
which allows us to use the hash of the NFD form.
rdar://17498444
Swift SVN r20543
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20518
This was added for benchmarking purposes, without the realization that
it conflicts with the NSString API we adopt when importing Foundation.
http://oleb.net/blog/2014/07/swift-strings/#comparing-strings describes
the problem.
Fixes <rdar://problem/17800504>
Swift SVN r20517
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20495
...because their semantics were unclear. The new idiom is explicit
construction of the target type using the "bitPattern:" argument label:
myInt.toUnsigned() => UInt(bitPattern: myInt)
Fixes <rdar://problem/17000821>
Swift SVN r20479
Array literal construction currently goes through an expensive dance;
Adding _allocateUninitialized will allow SILGen to do something much
smarter.
Swift SVN r20448
This way, array optimization can see initialization as a copy of the
whole array value into a local variable, regardless of whether it's
from a factory method or Array initializer.
I'm making an assumption that when we return an Array by value, we
can't have an alias of the array buffer without retaining it.
Swift SVN r20444
also, dump a bunch of other init() functions from other types.
Fixes <rdar://problem/16925296> #Seed 5: Remove unneeded String initializers
Swift SVN r20395