When calling _getOwner at this point we know that it is a native array.
This simplifies the SIL code for assigning a class array element (a[i] = x).
Swift SVN r27124
We define two new library functions _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC, similar to _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC. The main difference is that they require their arguments to conform to _BridgedToObjectiveC and _BridgedToObjectiveC. _ObjectiveCType accordingly. With this change, it is now possible to invoke the _BridgedToObjectiveC._forceBridgeFromObjectiveC witness directly, without going via the inefficient swift_bridgeNonVerbatimFromObjectiveC.
So now, for a cast O -> S, if it can be statically proven that an ObjC type O is bridgeable to a Swift type S implementing the _BridgedToObjectiveC protocol (i.e. O is the class (or its subclass) defined by the S._ObjectiveCType alias), we can generate a code to invoke the newly defined library function _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC instead of _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC.
After inlining, this will end-up invoking S._forceBridgeFromObjectiveC directly instead of invoking a more general, but less effective swift_bridgeNonVerbatimFromObjectiveC, which always performs conformance checks at runtime, even if conformances are known statically. As a result, no conformance checks are performed at run-time if conformances are known statically.
The client code making use of these new APIs and the tests are coming in the subsequent commits.
The naming of the two new helper library functions was discussed with Dmitri.
This is part of the bridging casts optimization effort. And it is specifically useful for e.g. rdar://19081345.
Swift SVN r27100
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r27092
The new mirror design passed our API review and blocking bugs have been
fixed/worked-around, so integrating it into the core standard library.
Swift SVN r27082
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r27081
If the NSError part of the box hasn't been initialized yet, fill it in with the domain and code of the contained value. This will allow us to efficiently turn ErrorType values into NSErrors, either for bridging or for coercion purposes.
Swift SVN r26958
Changes compared to the original version:
I fixed the 2 bugs and added a test for the so far undetected missing range check bug.
To keep the SIL simple (4 basic blocks for arr[x]) I extracted the slow path for getElement into a
non-inlinable function.
On the other hand I inlined _typeCheck into the slow-path function.
This speeds up NSArray accesses because now only a single objectAtIndex is required for both
type checking and element retrieving.
Update on performance: DeltaBlue is now only 12% better (and not 25%). I suspect this is because
now Arnold's tail duplication cannot detect the ObjC call in the slow path.
Swift SVN r26935
The performance regression that occurred when ++ and -- were added as
requirements to the Index protocols was due to the fact that it caused a
dubious hack of mine to be bypassed: when treated as indices, integer
types are incremented and decremented without overflow checking. While
technically justifiable (see the r20576 commit message), this makes the
standard library extremely fragile and makes successor() and
predecessor() mathematically unsafe. We really should see what the
optimizer team can do to make that hack unnecessary.
In the meantime, instead of dispatching through ++ and --, use a
special, defaulted _[successor|predecessor]InPlace() method to give
indices their own, customizable in-place inc/dec-rement path.
Swift SVN r26926
Retire the old components now that the new ones have passed API review.
<rdar://20406937> covers the migration fallout of this change.
Swift SVN r26904
Now that we can check isNative and NoDTC (no deffered type check needed) with a single bit-mask operation,
it makes sense to have a single array property call for it.
I replaced the the semantics call array.props.needsElementTypeCheck with array.props.isNativeNoDTC,
which is the combination of isNative && !needsElementTypeCheck. I kept array.props.isNative, which is not used for now,
but might be useful in the future, e.g. for array operations which don't care about type checks.
The optimized SIL for a class array access arr[i] now contains the minimum of 4 basic blocks.
PerfTests show +25% for DeltaBlue and some improvemements for -Onone.
Swift SVN r26871
'x is P' works now, and this function isn't used anywhere except by a test that exercises it. Removing this also lets us remove a swath of otherwise unused helper static functions in the runtime.
Swift SVN r26618
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.
Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.
Swift SVN r26508
We have an SPI between the Swift compiler and Foundation based on the
SWIFT_SDK_OVERLAY_FOUNDATION_EPOCH preprocessor macro that allows us to
request the new API. rdar://20270080 tracks removing it.
Swift SVN r26475
With this change we will devirtualize in trivial cases where mandatory
inlining has exposed opportunities due to substituting types, for
example substituting a struct type into a witness_method where we can
now easily determine exactly what method will be called.
This makes it possible to use @transparent on struct methods that are
dispatched via generic functions, resulting in the opportunity to emit
diagnostics for these methods as well as eliminate the overhead of the
indirect call.
I saw a handful of 10+% perf improvements at -Onone on our benchmarks.
In theory this should allow us to remove the overloads for ++/-- in
FixedPoint.swift.gyb without a performance penalty (and with the proper
overflow diagnostics), but unfortunately if we were to do so, we would
currently dispatch to functions that lack runtime overflow
checks (rdar://problem/20226526).
Swift SVN r26397
