Preparation to fix <rdar://problem/18151694> Add Builtin.checkUnique
to avoid lost Array copies.
This adds the following new builtins:
isUnique : <T> (inout T[?]) -> Int1
isUniqueOrPinned : <T> (inout T[?]) -> Int1
These builtins take an inout object reference and return a
boolean. Passing the reference inout forces the optimizer to preserve
a retain distinct from what’s required to maintain lifetime for any of
the reference's source-level copies, because the called function is
allowed to replace the reference, thereby releasing the referent.
Before this change, the API entry points for uniqueness checking
already took an inout reference. However, after full inlining, it was
possible for two source-level variables that reference the same object
to appear to be the same variable from the optimizer's perspective
because an address to the variable was longer taken at the point of
checking uniqueness. Consequently the optimizer could remove
"redundant" copies which were actually needed to implement
copy-on-write semantics. With a builtin, the variable whose reference
is being checked for uniqueness appears mutable at the level of an
individual SIL instruction.
The kind of reference count checking that Builtin.isUnique performs
depends on the argument type:
- Native object types are directly checked by reading the
strong reference count:
(Builtin.NativeObject, known native class reference)
- Objective-C object types require an additional check that the
dynamic object type uses native swift reference counting:
(Builtin.UnknownObject, unknown class reference, class existential)
- Bridged object types allow the dymanic object type check to be
bypassed based on the pointer encoding:
(Builtin.BridgeObject)
Any of the above types may also be wrapped in an optional. If the
static argument type is optional, then a null check is also performed.
Thus, isUnique only returns true for non-null, native swift object
references with a strong reference count of one.
isUniqueOrPinned has the same semantics as isUnique except that it
also returns true if the object is marked pinned regardless of the
reference count. This allows for simultaneous non-structural
modification of multiple subobjects.
In some cases, the standard library can dynamically determine that it
has a native reference even though the static type is a bridge or
unknown object. Unsafe variants of the builtin are available to allow
the additional pointer bit mask and dynamic class lookup to be
bypassed in these cases:
isUnique_native : <T> (inout T[?]) -> Int1
isUniqueOrPinned_native : <T> (inout T[?]) -> Int1
These builtins perform an implicit cast to NativeObject before
checking uniqueness. There’s no way at SIL level to cast the address
of a reference, so we need to encapsulate this operation as part of
the builtin.
Swift SVN r27887
Semantic analysis should be guaranteeing that all conformances that
show up in the AST are complete. Until that day, work around the crash
in rdar://problem/20700616 by not specializing.
Swift SVN r27886
emit{StrongRelease,ReleaseValue} => emit{StrongRelease,ReleaseValue}AndFold.
Then introduce a new method emit{StrongRelease,ReleaseValue} that returns a
PointerUnion containing the increment to be deleted if it exists. This obviates
the need for the callback.
Swift SVN r27804
Previously, we relied on certain types not being passed in by the users of the
given function. Since I had a lot on my plate on the time and I knew it was safe
I left it in. Now I am going to be using this function in more places so it
needs to handle everything correctly.
rdar://19552593
Swift SVN r27748
In r26152 a crash was fixed that had been introduced by previous
improvements, but as a result of fixing the crash some cases where we
previously devirtualized were disabled with the intent that they would
be reenabled after further refactoring work was completed.
This commit restores that functionality and reenables the tests.
Swift SVN r27575
This updates the performance inliner to iterate on inlining in cases
where devirtualization or specialization after the first pass of
inlining expose new opportunities for inlining. Similarly, in some cases
inlining exposes new opportunities for devirtualization, e.g. when we
inline an initializer and can now see an alloc_ref that allows us to
devirtualize some class_methods.
The implementation currently has some inefficiencies which increase the
swift compilation time for the stdlib by around 3% (this is swift-time
only, no LLVM time, so overall time does not grow by this much).
Unfortunately the (unchanged) current implementation of the core
inlining trades off improved estimates of code growth for increased
compile time, and that plays a part in why compile time increases as
much as it does. Despite this, I have some ideas on how to win some of
that time back in future patches.
Performance differences are mixed, and this will likely require some
further inliner tuning to reduce or remove some of the losses seen here
at -O. I will open radars for the losses.
Wins:
DeltaBlue 10.2%
EditDistance 13.8%
SwiftStructuresInsertionSort 32.6%
SwiftStructuresStack 34.9%
Losses:
PopFrontArrayGeneric -12.7%
PrimeNum -19.0%
RC4 -30.7%
Sim2DArray -14.6%
There were a handful of wins and losses at Onone and Ounchecked as
well. I'll review the perf testing output and open radars accordingly.
The new test case shows an example of the power of the closer
integration here. We are able to completely devirtualize and inline a
series of class_method applies (10 deep in this case, but in theory
substantially deeper) in a single pass of the inliner, whereas before we
could only do a single level per pass of inlining & devirtualization.
Swift SVN r27561
reference to something of class type. This is required to model
RebindSelfInConstructorExpr correctly to DI, since in the class case,
self.init and super.init *take* a value out of class box so that it
can pass the +1 value without performing an extra retain. Nothing
else in the compiler uninitializes a DI-controlled memory object
like this, so nothing else needs this. DI really doesn't like something
going from initialized to uninitialized.
Yes, I feel super-gross about this and am really unhappy about it. I
may end up reverting this if I can find an alternate solution to this
problem.
Swift SVN r27525
Even when we don't know for sure if a bridged cast would succeed, we still want to lower it to produce a more efficient code that does not performs conformance checks at run-time.
This is useful when performing casts optimizations as a guaranteed optimization.
Swift SVN r27377
It was producing a checked_cast_add_br, which took a metatype inst as it's argument, which is simply wrong, as it is not an address type. SILVerifier was complaining about it. Now we produce an equivalent peephole, but with a correct instruction sequence, which makes SILVerifier happy.
Swift SVN r27375
Sometimes, during intermediate optimization steps, the operands of produced checked_cast_addr_br instructions do not actually have address types.
Don't try to optimize further in such cases. Let the optimizer clean-up those instructions.
Swift SVN r27373
I noticed under Instruments that the bridged casts opts produced a code that was leaking in some cases. Therefore I took the change to re-visit the code and to clean-up the logic for insertion of retains and releases.
Swift SVN r27371
When casts optimizations were lowering bridged casts from ObjC to Swift, they were producing internally an intermediate cast from an ObjC type into the expected ObjC type of a bridged cast, before converting this expected ObjC type into a Swift type. In many cases, this resulted in a useless intermediate cast where both types were the same and such a cast would be eliminated afterwards. E.g.
unconditional_checked_cast A to B // where A is ObjC type and B is a Swift type
was lowered into:
unconditional_checked_cast A to B. _ObjectiveCType // Often useless as A is equal to B. _ObjectiveCType already.
unconditional_checked_cast B._ObjectiveCType to B
This small inefficiency is fixed now. This problem was no observable from outside the optimization pass, it just required additional processing, therefore there is no test-case.
Swift SVN r27370
During inlining we'll now attempt to first devirtualize and specialize
within the function that we're going to inline into. If we're successful
devirtualizing and inlining, and we'll attempt to inline into the newly
exposed callees first, before inlining into the function we began with.
This does not remove any existing passes of devirtualization or
specialization yet, partially because we don't completely handle all
cases that they handle at this point (e.g. specializing partial
applies).
We do end up specializing deeper into the call graph with this approach
than we did prior to this commit.
I will have some follow-on changes that integrate things further,
allowing us to devirtualize in more cases after inlining into a given
function.
I will also add some directed tests in a future commit.
I tested the stdlib build and this made no difference in build
times. Perhaps after removing other existing phases we'll recapture some
build time.
I'm not seeing reproducible performance differences with this change,
which is not a big surprise at this point. This sets us up for being
able to improve the compilation pipeline in a future release.
Swift SVN r27327
This is new attribute we're using to coalesce @thin, @objc_block, and @cc, and to extend to new uses like C function pointer types. Parse the new attribute, but preserve support for the old attributes, and print with the old attributes for now to separate out test changes. Migration fixits and test updates to come. I did take the opportunity here to kill off the '@cc(cdecl)' hack for AST-level function pointer types, which are now only spelt with @convention(c).
Swift SVN r27247
Fixed the logic in getSubstitutionsForSuperclass and renamed it into getSubstitutionsForCalleee to better reflect what it does.
rdar://20440616
Swift SVN r27166
If a conformance to _BridgedToObjectiveC is statically known, generate a more efficient code by using the newly introduced library functions for bridging casts.
This covers the casts resulting from SIL optimizations.
Tests are included. I tried to cover most typical casts from ObjC types into Swift types and vice versa and to check that we always generate something more efficient than a checked_cast or unconditional_checked_cast. But probably even more tests should be written or generated by means of gyb files to make sure that nothing important is missing.
The plan is to make the bridged casts SIL optimization a guaranteed optimization. Once it is done, there is no need to lower the bridged casts in a special way inside Sema, because they all can be handled by the optimizer in a uniform way. This would apply to bridging of Error types too.
With this change, no run-time conformance checks are performed at run-time if conformances are statically known at compile-time.
As a result, the performance of rdar://19081345 is improved by about 15%. In the past, conformance checks in this test took 50% of its execution time, then after some improvements 15% and now it is 0%, as it should be.
Swift SVN r27102
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
swift::clearBlockBody() in Local.cpp was popping instructions rather
than erasing them, resulting in leaking any instructions removed via
this function (which is reached via removeDeadBlock(), called throughout
SimplifyCFG).
Also tweak a couple comments and remove an assert that cannot fire.
Swift SVN r27018
Add more checks and logic into emitSuccessfulIndirectUnconditionalCast and emitSuccessfulScalarUnconditionalCast, so that its clients in sil-combine can be simplified by avoiding looking into special cases.
Swift SVN r26885
If current checked_cast_br is reachable via success, failure and unknown at the same time, then we simply don't know the outcome of the dominating check.
No jump-threading should be performed in this case.
I'll commit the test-case tomorrow. The test-case from the radar depends too much on the stdlib internals. We need something smaller and simpler.
rdar://20389307
Swift SVN r26841
This leaves nothing but the helper for specializing an ApplySite in
Generics.h/Generics.cpp, and I expect to rename these files accordingly
at some point.
Swift SVN r26827
