Swift generates two entry points to @objc methods where one of
them is a thunk, and the inliner happily inlines the swift code
into the @objc thunk, effectively doubling the code size of some
@objc classes.
The performance inliner already knows not to inline large functions
into callers that are marked as thunks. This commit adds the [thunk]
attribute to the @objc thunks in an attempt to reduce code size.
rdar://22403108
Swift SVN r31498
The only caveat is that:
1. We do not properly recognize when we have a let binding and we
perform a guaranteed dynamic call. In such a case, we add an extra
retain, release pair around the call. In order to get that case I will
need to refactor some code in Callee. I want to make this change, but
not at the expense of getting the rest of this work in.
2. Some of the protocol witness thunks generated have unnecessary
retains or releases in a similar manner.
But this is a good first step.
I am going to send a large follow up email with all of the relevant results, so
I can let the bots chew on this a little bit.
rdar://19933044
Swift SVN r27241
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
This lets us disambiguate the symbols for static and instance properties, and enables us to eventually leave the useless "self" type mangling out of method symbols. Fixes rdar://19012022 and dupes thereof, including crasher #1341.
Swift SVN r25111
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
them in a more consistent and principled way. Two changes here: MUI is generated
when a vardecl is emitted, not as a separate "MarkPatternUninitialized" pass. Second,
when generating a MUI for self parameters with a temporary alloc_stack (due to the
possibility of superclass remapping of self) emit the MUI on the allocation itself,
not on the incoming argument. This is a lot more consistent (dissolving a bunch of
hacks in DI).
In terms of behavior changes, this only changes the raw sil generated by SILGen and
consumed by DI, so there is no user-visible change. This simply unblocks future work.
Swift SVN r23823
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
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 eliminates the workaround for propagating 'nil' from Objective-C
initializers up through Swift initializers, now that failable
initializers handle this propagation.
Swift SVN r21706
When we introduce a method into a class extension (such that it does
not override any other method), we cannot add a vtable slot for that
method and therefore cannot perform dynamic dispatch on it without
going through objc_msgSend. To work around this bug
(<rdar://problem/17950064>), infer 'dynamic' for these cases, which
pushes us through objc_msgSend to get the appropriate semantics.
Note that we do *not* want this to interfere with inference of
'final', which means allowing 'final' inference to delete the
'dynamic' we introduce with the above.
Swift SVN r21135
Teaches TryAddFinal to descend into public and objc classes. Only
tries to add final if we're either whole compilation mode, or we're
processing the primary source buffer.
Updates test cases. Includes workarounds for <rdar://problem/17860781>
and <rdar://problem/17862348>.
Swift SVN r20790
Run whole-module checks at the end of perform Sema, specifically
TryAddFinal. After everything has been type checked, accessibility has
been provided, and we have had a chance to see any potential
overrides, we try to add the final attribute to class members.
This ends up de-virtualizing many functions, or rather they avoid the
vtable altogether. Thus, there are many test file changes. New test
file add_final.swift. Other tests updated to either reflect the
non-virtual call, or to have public added to them.
Swift SVN r20338
CALayer and potentially other framework classes implement their own refcounting
schemes that assume [self retainCount] == 1 at initialization time, a guarantee
SILGen didn't attempt to meet until now. Set a flag in SILGenFunction while
doing initializer delegations to indicate that a 'self' reference can consume
the current 'self' binding, and reinitialize rather than reassign 'self' with
the result of the delegation if it was successfully consumed. Fixes
<rdar://problem/17014037>.
Swift SVN r18608
