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
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
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
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
Primarily, this means becoming resilient to Builtin.strideof(x) == 0.
Pretty much the only way to get pointers and arrays to make sense is to
treat zero-sized elements as having a stride of 1, so we do that in our
wrapper for Builtin.strideof. Other points include precondition checks
for radixes in number formatting.
Fixes <rdar://problem/17097768>
Swift SVN r20242
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
We're temporarily using @semantics until we have mandatory inlining of branch hints.
We now have @noinline, which helps a lot, but:
- @noinline and "cold/slow" are not the same thing.
- Some functions may need to be inlined into hot paths, but that
doesn't mean we should also inline them into cold paths.
- It is easier to find cold blocks than to look for blocks that
contain calls to @noinline functions. And that doesn't necessarilly
mean the blocks are cold anyway.
Swift SVN r19455
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
Revert "[stdlib] Use an enum for ArrayBuffer storage"
This reverts commit r18996.
This reverts commit r18954.
The optimizer is not ready yet to handle this change especially given
the time until Beta 3. After speaking with DaveA, we agreed to revert
this and take such large changes onto private branches until we are sure
that the optimizer is ready to handle them rather than risking
performance regressions due to hitting the "optimization cliff".
Swift SVN r19026
instead of reinterpretCasting all over the place. This should make it
easier on the ARC optimizer.
Addresses <rdar://problem/17312221>
Swift SVN r18954
This not only removes some code, but should allow more optimization and
inlining in the common case where the Swift type is a class or @objc
existential such as AnyObject
Swift SVN r18237
assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
