Specifically, make sure that any all function_refs produced by the devirtualizer inside fragile functions never reference a private or hidden symbol.
For example, the transparent function body can’t expose private symbols to other modules that may try to inline it.
rdar://21408247
Swift SVN r29405
I didn't add anything to the table, just made use of what was already there.
We have plenty of additional calls to getIdentifier that could probably benefit
from this kind of easy access as well.
This commit also removes FOUNDATION_MODULE_NAME and OBJC_MODULE_NAME from
Strings.h. Neither of these is likely to change in the future, and both
already have KnownIdentifiers equivalents in use.
No intended functionality change.
Swift SVN r29292
I needed this for nontrivial DeadObjectElimination.
This also makes the order that we remove uses and insert releases
deterministic (although order of removal should not be required).
The utility only does what it needs to do, nothing more. The result is
separate from the Analysis. ValueLifetimeAnalysis does not impose any
structure on the client. The client decides how to transform or filter
the user list. The client that uses the Analysis can access its
internal book-keeping and helpers.
I should be able to migrate ReleaseTracker easily.
Swift SVN r29165
checked_cast_br promises to maintain RC identity, but a cast from an ErrorType-conforming class to NSError may change the RC identity by bridging. Make sure that potential class-to-NSError casts go through the indirect cast entry points for now. The runtime implementation still needs to be fixed to handle the class-to-NSError case, but this is part of rdar://problem/21116814.
Swift SVN r29089
And also adapt a whole set of SIL passes so that they can deal with (the not deleted) debug_value instructions.
This was required to prevent perforamnce and code size regressions.
Now the generated code is (almost) the same as before.
The effect of this change is that we keep debug_value/debug_value_addr also in optimized code (more or less).
Fixes rdar://problem/18709125.
Swift SVN r28872
Why did I choose to pollute the call graph? Because it's convenient,
efficient, and more robust than any current alternative. This is a
property of the parent function that depends on all the call sites. We
need to cache this information somehow and update it whenever edges
are added to the call graph. The call graph does this perfectly.
The thing I don't like is that it is conservative and may not return a
precise answer after updates, which is generally undesirable. You
normally want to get the same answer whether you update or recompute
an analysis. Although this is generally bad, it is a good tradeoff
now. The need for this call graph property is a consequence of the
current SIL representation which should change soon. It only comes up
in bizarre corner cases, and the imprecision will never show up in
practice.
Swift SVN r28784
It is not safe to dyn_cast the result to a SILInstrucion. Users of this function
expect a nullptr return to mean no change has happened. If the operand was an
argument this cast would fail although we have removed the cast instruction and
changed the function.
rdar://20991580
Swift SVN r28684
The existing implementation of this peephole was miscompiling when some arguments of a partial_apply were alloc_stack, because some of they could be dead before the apply which uses the partial_apply. To fix this problem I had to re-factor the implementation. Earlier we were looking for an apply first and then for a partial_apply it uses. With this patch, we do it the other way around: we fist look for a partial_apply and then peephole all apply instructions referring to it in one go. To solve the problem with "prematurely" dead alloc_stack arguments, we introduce new temporaries with a longer lifetime and copy the original arguments into them.
The test-cases are extended with more complex examples, including usage of existentials.
This fixes the compile-time crasher in test/Interpreter/currying_generics.swift
rdar://20868728
Swift SVN r28570
Fixes <rdar://problem/20044992> Swift: Generic functions called from
class methods with type parameter inferred to Self compiles, breaks
type system under optimization
If we don't prohibit specialization then we silently miscompile by
assuming a base class instead of the dynamic type.
It is unclear to me why GenericFunctionType did not inherit any
recursive type properties from it's arguments and result. However, it
I think it makes sense to propagate DynamicSelfType into
GenericFunctionType so I've broke with convention here.
Swift SVN r28541
We don't serialize their bodies because we only want them in the stdlib dylib.
Marking them Shared changes their visibility to hidden and the linker gets angry
when it tries to link their symbol in another object.
rdar://20907669
Swift SVN r28536
If the target ObjC type of a bridged cast is not the exact type being expected, but one of its superclasses, perform an upcast (e.g. upcast NSArray to NSObject).
rdar://20869055
Swift SVN r28319
- The cast optimiser was asserting if it could not find the _forceBridgeFromObjectiveC implementations in the Foundation module (where all stdlib bridged types reside). Now it checks the module being compiled as well.
- If a bridging function cannot be found, don't assert and bail out instead. After all, it is just an optimization and even if it cannot be applied, we should not crash.
This makes Swift :: 1_stdlib/ArrayBridge.swift compile with -O.
rdar://20845536
Swift SVN r28295
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
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
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
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
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
threaded into IRGen; tests to follow when that's done.
I made a preliminary effort to make the inliner do the
right thing with try_apply, but otherwise tried to avoid
touching the optimizer any more than was required by the
removal of ApplyInstBase.
Swift SVN r26747
Use existing machinery of the generic specializer to produce generic specializations of closures referenced by partial_apply instructions. Thanks to the newly introduced ApplyInstBase class, the required changes in the generic specializer are very minimal.
rdar://19290942
Swift SVN r26582
We no longer need or use it since we can always refer to the same bit on
the applied function when deciding whether to inline during mandatory
inlining.
Resolves rdar://problem/19478366.
Swift SVN r26534
When creating a new apply, we were copying the transparent bit from the
old apply, as well as the referenced function from the old apply. We
should just use the transparent bit from that referenced function.
Swift SVN r26384
Transforms :
%1 = alloc_ref $B
checked_cast_br [exact] %1 : $B to $B, bb1, bb2
into
br bb1(%1 : $B)
In case when source and destination types do no match, replace by a branch to the failure bb of the checked_cast_br.
Swift SVN r26275
TerminatorInsts. Now you can walk over the successor list of a terminator
and actually modify the SILSuccessor directly, allowing better CFG
transformations. NFC.
Swift SVN r26140
