the type
Printing Float32 with %0.15g not only wastes screen space, but also causes
confusion for users, and pretends that a Float32 has more precision than it
actually does.
rdar://18043123
Swift SVN r21435
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
The syntax being reverted added busywork and noise to the common case
where you want to say "I have the right address, but the wrong type,"
without adding any real safety.
Also it eliminated the ability to write UnsafePointer<T>(otherPointer),
without adding ".self" to T. Overall, it was not a win.
This reverts commits r21324 and r21342
Swift SVN r21424
We have not defined whether readnone would potentially allow it to be
speculatively executed which is not desired semantics for
_swift_isClassOrObjCExistential because the metadata might not have been loaded
at the speculative point. Since we don't need the readnone property on this
function after the Builtin.canBeClass change for performance remove it for now.
This reverts commit r21330.
Swift SVN r21422
The buffer argument of _arrayReplace was a protocol and it forced
all of the calls to that member to be virtually dispatched and generic.
This boosts DeltaBlue by 2X.
Swift SVN r21405
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
