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
Naturally, the fast path for things like Array<Int> has to be that no
masking is required to get at the buffer. Therefore, the state with no
spare bits set needs to be reserved for native objects. After the
change, an ObjC non-tagged pointer is stored with all spare bits set, and
native objects are stored with 0..<N bits set, where N is the number of
spare bits. ObjC tagged pointers are still stored verbatim.
Swift SVN r23430
Renames swift_class_getInstanceSize to
swift_class_getInstancePositiveExtentSize to reflect that it is
the size of the object after the instance address point.
Swift SVN r23333
This is acting as a temporary work around until the more general
getTypeKind() is finalized from an API perspective.
The reason that removing this now instead of waiting makes sense is:
1. The previous way playgrounds was performing this check was using the runtime
c++ implementation of swift_isClassOrObjCExistential via @asmname. We
want to move away from the @asmname approach in general since it is
brittle since it leads to loose cupling of dependencies.
2. The @asmname version in playgrounds caused the deserializer to assert since
the c++ version of swift_isClassOrObjCExistential() does not match the signature
of the swift declaration of swift_isClassOrObjCExistential().
This allows us to avoid the aforementioned issues and make forward
progress on re-enabling the playground logger with optimization.
rdar://18841292
Swift SVN r23307
A revamped version of HeapBuffer that doesn't allow null buffer
references. Something like this is needed for killing the null array
state.
Swift SVN r22683
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
