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
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
We lazily realize classes when we access their metadata now, so there's no need to force the ObjC runtime to do this greedily anymore, except for classes that the runtime statically references. For those cases, add an @objc_non_lazy_realization class attribute that will put that class reference in the nlclslist section.
Swift SVN r23105
This is the barest-minimum change required to ensure that the buffer is
never nil. Codegen problems were crushing all more-ambitious
efforts (radar to follow)
Swift SVN r22959
This is mostly just a renaming of _SwiftNativeNSArray, except that we
want to add another NSArray subclass for verbatim-bridged elements, so
we want a common base class. _SwiftNativeNSArray is the name of that
new base class, to parallel the other _SwiftNativeNSXXX classes.
Swift SVN r22913
The buffer stored in a _ContiguousArrayBuffer<T> is not always
_ContiguousArrayStorage<T>. It might in fact be the special empty
buffer class.
Swift SVN r22835
The buffer stored in a _ContiguousArrayBuffer<T> is not always
_ContiguousArrayStorage<T>. It might in fact be the special empty
buffer class.
Swift SVN r22823
Buffer identity is only used by tests. The switch to an identity
representation that accounts for the buffer length was actually
incorrect for the way many tests used it.
Swift SVN r22771
Fixes rdar://problem/18646425
Running the test uncovered avoidable inefficiencies in Array copying, so
dispatch of _copyToNativeArrayBuffer was revamped. It's reasonable to
expect some speedups from this.
Also, the internal Array API requestNativeBuffer was highly error prone
when the source was a Slice, because it could return an array buffer
that represented more than the entire slice. That capability was
probably used for optimization once, but is no longer, and the error
prone API probably caused bugs, so it was reformed.
Swift SVN r22746
They were never really useful to users, because their APIs were
insufficiently public. They have been replaced with a single class,
ManagedBuffer<Value,Element>, which is really designed for user
consumption.
Swift SVN r22636
Now that <rdar://problem/18540783> is fixed, we can stop allocating the
empty array buffer dynamically and go back to using the one that is
statically laid out in GlobalObjects.cpp, thereby avoiding the
atomic instructions required to make it threadsafe.
Swift SVN r22545
NFC, and no significant performance change expected. This is part one
of a move to eliminate nil checks from the array implementation.
Swift SVN r22526
NFC, and no significant performance change expected. This is part one
of a move to eliminate nil checks from the array implementation.
Swift SVN r22495
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.
Swift SVN r22408
A collection whose count changes between traversals could cause a memory
safety problem, as we would measure the collection in one pass and
assume that it was the same length when actually initializing array
elements. Fix that by always using the initial measurement, which
corresponds exactly to allocated memory. If the collection wants to
trap because we've gone past its new bounds, that's fine. If it
doesn't, at least we haven't done anything unsafe.
Swift SVN r22152
Array did not initialize fast enumeration state if it was empty.
Surprisingly, this did not break code that is generated by Clang
currently. (But as far as I understand fast enumeration, it may abort
the program because mutation pointer is null.)
Swift SVN r21940
When creating an array from a SequenceType not statically known to be a
CollectionType, don't neglect to pre-allocate based on its
underestimated count.
Swift SVN r21829
This should allow us to better optimize repeated push/pop benchmarks.
I didn't notice a performance change at the time I did this. I'm just
putting it in as a hopefully obvious drive-by fix.
Swift SVN r21429
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
