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
This encapsulates common operations on array semantic calls like identifying
them or hoisting/copying them.
Will be used by follow-up commits. NFC.
Swift SVN r21926
This looks for @effects(readnone) on functions. A follow up commit will mark
_swift_isClassOrObjCExistential as readnone allowing us to CSE it.
rdar://17961249
Swift SVN r21285
Expose Substitution's archetype, replacement, and conformances only through getters so we can actually assert invariants about them. To start, require replacement types to be materializable in order to catch cases where the type-checker tries to bind type variables to lvalue or inout types, and require the conformance array to match the number of protocol conformances required by the archetype. This exposes some latent bugs in the test suite I've marked as failures for now:
- test/Constraints/overload.swift was quietly suffering from <rdar://problem/17507421>, but we didn't notice because we never tried to codegen it.
- test/SIL/Parser/array_roundtrip.swift doesn't correctly roundtrip substitutions, which I filed as <rdar://problem/17781140>.
Swift SVN r20418
Fixes part of <rdar://problem/16196801>.
Inline generic functions, but only when:
- There are no unbound archetypes being substituted (due to various
assumptions in TypeSubstCloner about having all concrete types).
- When no substitution is an existential (due to
<rdar://problem/17431105>, <rdar://problem/17544901>, and
<rdar://problem/17714025>).
This gets things limping along, but we really need to fix the above
limitations so that mandatory inlining never fails.
This doesn't enable inlining generics in the performance inliner. There
is no reason it shouldn't work as well, but there is no compelling
reason to do so now and it could have unintended effects on performance.
Some highlights from PreCommitBench -
O0:
old (ms) new (ms) delta (ms) speedup
ForLoops 1127.00 294.00 833.00 283.3%
LinkedList 828.00 165.00 663.00 401.8%
R17315246 982.00 288.00 694.00 241.0%
SmallPT 3018.00 1388.00 1630.00 117.4%
StringWalk 1276.00 89.00 1187.00 1333.7%
-- most others improve ~10% --
O3:
old (ms) new (ms) delta (ms) speedup
Ackermann 4138.00 3724.00 414.00 11.1%
Life 59.00 64.00 5.00 -7.8%
Phonebook 2103.00 1815.00 288.00 15.9%
R17315246 430.00 582.00 152.00 -26.1%
StringWalk 1173.00 1097.00 76.00 6.9%
Ofast:
old (ms) new (ms) delta (ms) speedup
Ackermann 3505.00 3715.00 210.00 -5.7%
Life 49.00 41.00 8.00 19.5%
Memset 684.00 554.00 130.00 23.5%
Phonebook 2166.00 1769.00 397.00 22.4%
StringWalk 829.00 790.00 39.00 4.9%
I've opened the following to track remaining issues that need to be
fixed before we can inline all transparent function applications:
<rdar://problem/17431105>
<rdar://problem/17544901>
<rdar://problem/17714025>
<rdar://problem/17768777>
<rdar://problem/17768931>
<rdar://problem/17769717>
Swift SVN r20378
Previously in the aforementioned function, we drop the operands of the
instruction before we call the callback function.
This means that if, for instance, one was printing out that instruction,
the printer would blow up when it attempts to access the
instruction.
Swift SVN r20003
In a few places we were calling into a function that just returned
T->hasArchetype(). This just changes those places to test it directly.
Swift SVN r19427
While they do "write" to memory in terms of invalidating enums, that is
not a required operation, so it is ok to remove it.
rdar://16752890
Swift SVN r17654
See rdar://16676020 for details.
r17101 tries to solve r16761933 by checking non-direct recursions in
the call graph. We are in discussion of solving it in a different way.
Todo: figure out why r17101 causes a preformance regression.
Swift SVN r17265
Drill down into partial_apply to examine how the container pointer is
used within the partial_apply. If the uses are not unexpected, and do
not allow the container pointer to escape the partial_apply, then we'll
check how the partial_apply is used when passed into an apply by
drilling down one level into that apply (but no further). If the
partial_apply itself cannot escape the current function or any funtion
it is passed to, then we should be able to clone the partial_apply body
and rewrite it to remove the box container pointer (coming in a future
commit).
This is all effectively disabled now by passing false to the call to
canValueEscape in findUnexpectedBoxUse which disables drilling down into
the apply.
Swift SVN r15591
r15322 reworked the logic for determining where the final releases are,
which means that we no longer need to collect the uses and releases as
we evaluate candidates for promotion.
Swift SVN r15333
We need to adjust the index by the number of actual arguments used in
the partial apply.
There's no way to test this at this time as the only pass using this is
allocbox-to-stack, and that pass ends up bailing out due to the
ObjectPointer for the box also getting passed to the partial_apply.
No diffs compiling stdlib.
Swift SVN r15183
specialize on polymorphic arguments.
This can be enabled with: -sil-devirt-threshold 500.
It currently improves RC4 (when enabled) by 20%, but will be much more
important after Michael's load elimination with alias analysis lands.
This implementation is suitable for experimentation. Superficial code
reviews are also welcome. Although be warned that the design is overly
complex and I plan to rewrite it. I initially abandoned the idea of
incrementally specializing one function at a time, thinking that we
need to analyze full chains. However, I since realized after talking
to Nadav that the incremental approach can be made to work. A lot of
book-keeping will go away with that change.
TODO:
- Resolve protocol argument types. Currently we assume they can be
reinitialized at applies, but I don't think they can unless they are
@inouts. This is an issue with the existing local devirtualizer
that prevents it working across calls.
- Properly mangle the specialized methods. Find existing
specializations by demangling rather than maintaining a map.
- Rewrite the logic for specializing chains for simplicity.
- Enable by default.
Swift SVN r13642
Have SILGen mark all variables bound from pattern bindings without initializers (and *only* ones without initializers) with mark_uninitialized [var] pseudo instructions. On the DI end, *only* consider mark_uninitialized instructions for DI analysis. This has many benefits:
- DI doesn't waste time analyzing locals that are trivially initialized in the original source code.
- DI doesn't try to mangle canonical SIL that has been inlined from transparent functions, which may have been optimized into a form DI isn't written to understand.
While we're here, fix an issue with DCE where it would try to kill unused MarkUninitialized instructions. Although MarkUninitialized has no side effects, it still is semantically important to raw SIL, and can't be killed.
Chris did most of the work here; I just finished updating tests and fixing bugs.
Swift SVN r13247
