The old design did not strictly keep track of the index in underlying
UTF16, which would have made converting between the different index
types too difficult. It also made equality comparison between indices
broken, because
UTF8Index(s.utf16.startIndex+1, within: s.utf8)
and
UTF8Index(s.utf16.startIndex, within: s.utf8).successor()
would often have completely different UTF8 buffers and offsets within
the underlying UTF16.
For some reason this disturbed SILPasses/devirt_default_case.swift,
which is now XFAIL'd. <rdar://problem/19298212>
SILPasses/devirt_default_case.swift is XFAIL'd
Swift SVN r24012
Even though it doesn't conform to RandomAccessIndexType without
Foundation loaded, we can implement these internal operations to happen
in O(1), which, e.g., should speed up count(s.utf16) among others.
Swift SVN r24009
This reverts commit 71eb477aa6d9354cbad7baebae4283936bb1831a.
Per Erik's review.
The correct fix is interprocedural analysis that has visibility
into specialized functions. Let's just wait for that.
Swift SVN r24007
dispatch_once calls on every load from it
Performance improvements, as reported by the perf testing buildbot:
Histogram -18.81%
TwoSum -17.42%
RGBHistogram -9.65%
Regressions:
InsertionSort 5.59%
ArrayOfRef 3.99%
SwiftStructuresInsertionSort 5.29%
PrimeNum 6.09%
These regressions are bogus. The tests that "regressed" don't do any
hashing at all.
Swift SVN r23995
variable
We were avoiding recomputing it because it used to be a slow operation.
Performance improvements, as reported by the perf testing buildbot:
Histogram -14.07%
StringUtilsUnderscoreCase -10.22%
Dictionary -10.75%
LevenshteinDistance -18.08%
Regressions:
* ArraySubscript 8.56%
This is just bogus. That test does not do any hashing.
* NSDictionaryCastToSwift 6.86%
This test does not do any hashing. It operates only on empty
dictionaries. I believe this is noise.
Swift SVN r23991
There had been some discussion of making this available iff Foundation
is loaded, but it turns out that there are almost no Foundation APIs
that return NSUInteger indices into NSStrings without first packaging
them into NSRanges, and when <rdar://problem/19255291> is addressed,
these NSRanges will become Swift Range's, which have a different
interface. So there's no seamless API transition to be had here, for
any substantial subset of code written against Cocoa.
Swift SVN r23949
This fixes one of the issues preventing optimization of RangeAssignment
when it isn't fully inlined. There is still another problem with this benchmark I haven't fixed:
<rdar://problem/19252374> We fail to fully optimize RangeAssignment. Forced inlining achieves 3-4x speedup.
This fix at least unblocks CopyForwarding, which perturbs inlining enough to expose the issue.
Swift SVN r23944
Rather than expose random access on String.UTF16View to all Swift users,
expose it only when Foundation is loaded. This effectively decouples
String from a UTF16 representation on non-Mac platforms.
Swift SVN r23929
We don't want to be locked into a UTF-16 representation on all
platforms, and when we implement String index conversion we really don't
want to extend the interface of Int.
Swift SVN r23928
The underlying problem is that e.g. even if a method is private but its class is public, the method can be referenced from another module - from the vtable of a derived class.
So far we handled this by setting the SILLinkage of such methods according to the visibility of the class. But this prevented dead method elimination.
Now I set the SILLinkage according to the visibility of the method. This enables dead method elimination, but it requires the following:
1) Still set the linkage in llvm so that it can be referenced from outside.
2) If the method is dead and eliminated, create a stub for it (which calls swift_reportMissingMethod).
Swift SVN r23889
Metatypes have no user-visible structure, but can at least summarize as their type names. This gives us reasonable ad-hoc Printable behavior (thought debugPrint is still wrong, since a type name isn't parsable without being .self'ed).
Swift SVN r23745
Use the recursive demangled name generation I implemented in _typeName for metatypes in _stdlib_getDemangledType as well, so that we get fully-qualified generic names and other goodness.
Swift SVN r23743
Sticking with the original design.
Also added a trap test for removeFirst() since its precondition
is that the set be non-empty, similar to Array.
Swift SVN r23712
rdar://problem/19132138
Make Set<T> visible by removing the underscore. Also, remove the pesky
${_Self} gyb variable that was for a temporary convenience in hiding Set.
Swift SVN r23699
Although Set.any will always return the same element when not modifying
the set, that is an implementation detail. It should be a method.
Swift SVN r23697
Rename in Set<T>:
func removeFirst() -> T
to
func removeAny() -> T?
var first: T?
to
var any: T?
- FWIW, `any` more closesly matches NSSet's `anyObject()` and constructs
in other languages, so `first` seems to be a bit of a surprise.
- `first` implies an ordering of some kind, iterating over `Set` as a
`SequenceType` does have a somewhat reliably "first" element, but it
also has a linguistic tension with the fact that Set<T> is
semantically unordered.
- `first` may be further confused if there ever is an OrderedSet<T>,
which ought to be the first element in its semantic ordering.
Swift SVN r23696
Intersect needs an intermediate set because we need to both traverse
and modify the left-hand side for the in-place operation, which can
invalidate the index.
Swift SVN r23666
The public API is mostly solid at this point, with only a few minor
changes to naming and a couple of extra methods to bring it to parity
with Array.
Also removed the quick-and-dirty operators <, >, <=, and >= which were
used as a convenient shorthand for strict subset, strict superset,
subset, and superset respectively (< is retained for Comparable
conformance).
Swift SVN r23657
This should help to optimize the range check in isValidSubscript to a single unsigned integer comparison.
But this is not done yet, because it also needs an optimization in llvm, which I'm currently working on.
Together with the llvm change there will be an performance improvement for array benchmarks, where the
range check cannot be hoisted out of a loop. E.g. ~ +30% on QuickSort.
Swift SVN r23583
It returns the argument and specifies that the value is not negative.
It has only an effect if the argument is a load or call.
The effect of this builtin is that for the load/call argument a positive range metadata is created in llvm ir.
I also added a public function _assumeNonNegative(x: Int) -> Int in the stdlib.
To be on the save side, I prefixed it with an underscore. But maybe it makes sense to make it available for all users.
Swift SVN r23582
This is just a basic implementation of each, with some questions
lingering about whether to do unicode normalization (and if so how),
but it gets things going.
Swift SVN r23572
This name is more consistent with the convention used throughout the
runtime: use underscores to separate the preconditions of partial
functions from the rest of their names.
Swift SVN r23505
