without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
The pass does not support this properly and given where we are in the schedule
it makes no sense to each the closure specializer how to do this at this time.
Swift SVN r22130
It is possible to teach the closure specializer to handle these cases but given
where we are in the schedule it makes no sense to try to teach the optimizer how
to handle it.
Keep in mind though that we *will* handle the case where the function being
passed the closure has out parameters. This means that generic functions like
reduce will still be able to be specialized if the closure being passed in does
not have generics in it at the AST level. This implies that we will not handle
specialized closures with indirect results either which is unfortunate.
Swift SVN r22126
This creates a nice separation in between the analysis and the dynamic part of
the specialization. Thus gatherCallSites only returns call sites that are legal
to specialize.
This makes it easier to track where all of the correctness checks are.
Swift SVN r22049
There are many instructions which do not contribute to the actual size of a
function that getFunctionCost knows to ignore. Thus this is more accurate.
rdar://18143825
Swift SVN r22007
This follows the model of dominance info and allows me to create reachability
methods on SILBasicBlock without creating dependencies from swiftSIL to
swiftSILAnalysis.
Swift SVN r21866
This will let the performance inliner inline a function even if the costs are too high.
This attribute is only a hint to the inliner.
If the inliner has other good reasons not to inline a function,
it will ignore this attribute. For example if it is a recursive function (which is
currently not supported by the inliner).
Note that setting the inline threshold to 0 does disable performance inlining at all and in
this case also the @inline(__always) has no effect.
Swift SVN r21452
PerfTests -----
Before
Totals,54,93821,93821,93821,0,0
Totals,54,86755,86755,86755,0,0
After
Totals,54,93610,93610,93610,0,0
Totals,54,85780,85780,85780,0,0
We may be able to tune BoostFactor for closure in PerformanceInliner.
Swift SVN r21312
If we have function A calls function B with a closure C
func A {
B(...) {
// closure C
}
}
and the inliner decides to not inline B into A, it may be beneficial to generate
a specialized version of B to have
func A {
B_spec_with_C(..., arguments_to_closure_C)
}
SILCombine will optimize apply of partial_apply that are both in B_spec_with_C.
Then inliner can inline the closure to B_spec_with_C.
For profitability, we check the relative size of the callee B and the closure C.
We also check hotness of the callsite to B in A and callsites to the closure
inside B. For now, if closure is called inside a loop, we think it is
profitable.
I will add this to the pass manager in a follow-up patch.
rdar://16569736
Swift SVN r21216
