This is needed for tests which define internal functions which should not be eliminated.
So far this was not needed because of a hack which prevented whole-module-optimizations for tests.
Swift SVN r22658
We serialize shared_external linkage as shared since:
1. shared_external linkage is just a hack to tell the optimizer that a
shared function was deserialized.
2. We can not just serialize a declaration to a shared_external function
since shared_external functions still have linkonce_odr linkage at the LLVM
level. This means they must be defined not just declared.
Swift SVN r22562
Since both shared and shared_external both lower to linkonce_odr, neither of
them can be declarations. This commit puts a check into the verifier to ensure
that this does not happen at the SIL level allowing us to catch such issues
earlier.
Swift SVN r22552
Eliminate the intermediate top_level_code function. Now that SIL is expressive enough to express a "main" function, there's no reason for it, and this eliminates a bunch of mystery code in IRGen to thunk from main to top_level_code by reaching for hardcoded symbol names. Demystify the special code for setting up C_ARGC and C_ARGV by having SILGen look for a transparent "_didEnterMain" hook in the stdlib and emit a call to it.
Swift SVN r22525
Those destructors are not referenced anywhere else in the SIL, but are used in the metadata
of a class. If they are private then dead function elimination would remove them.
This fixes <rdar://problem/18431856> unreachable executed at GenDecl.cpp:808
Swift SVN r22261
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
generates them.
Modify getAsCanonicalGenericSignature to dump same-type requirements last.
Also mix the conformance requirements on assocaited archetypes with the witness
markers.
SILParser used to put witness markers for all assocaited archetypes, then
add same-type requirements, and finally the conformance requirements on
associated archetypes. This causes mismatch types between deserialized
SILFunctionTypes and parsed SILFunctionTypes.
rdar://17998988
Swift SVN r21423
The second type of WitnessMarker for deserialized GenericSignature is null.
But the second type for parsed GenericSignature is not null, causing type
mismatch error when linking a SILFunction.
This commit ignores the second type of WitnessMarker when profiling the
GenericSignature.
rdar://17998988
Swift SVN r21178
We were already effectively doing this everywhere /except/ when building
the standard library (which used -O2), so just use the model we want going
forward.
Swift SVN r20455
*NOTE* This linkage is different from {Public,Hidden}External in that it has no
extra semantic meaning beyond shared.
The use of this linkage is to ensure that we do not serialize deserialized
shared functions. Those shared functions can always be re-deserialized from the
original module. This prevents a whole class of bugs related to the
creation of module cross references since all references to the shared
item go straight to the original module.
<rdar://problem/17772847>
Swift SVN r20375
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
We aren't going to be able to make these attributes meaningful to Swift source for 1.0, so reject them and recover by dropping them when resolving non-SIL types.
Swift SVN r16290
Entities with shared linkage are allowed to be discarded if they are unused even
in a library context.
Previously we implemented this in the serializer, which introduced
needless complications. Now we leave that responsibility to the optimizer giving
simplicity.
Swift SVN r16150
ObjC pointer types as UncheckedOptional.
Some of these changes are totally necessary; others may
simply reflect language/implementation work that hasn't
been done yet.
If anything seems particularly objectionable, bugs welcome.
Swift SVN r15783
When a particular class has no designated initializers explicitly
written or implicitly defined, complain and suggest initializers for
all of the stored properties that need them and appear to have
sensible default values. Fixes <rdar://problem/15670604>.
Swift SVN r15023
This will help with ensuring that we do not create multiple witness
table "definitions" one of which is null. That situtation yields an
IRGen assertion to be hit since the external declaration (in the guise
of a definition) has a different type from the actual deserialized
definition.
Swift SVN r14999
Currently this consists of private functions and shared functions. Even
though shared functions are technically serializable, we only want to
serialize them if their serialization is requested.
Swift SVN r14825
With this commit, we can deserialize the stdlib. Still running into
issues related to linking that requires a consultation with John. That
will come in a later commit.
Swift SVN r14365
lowered field type of a ref_element_addr's parent projection, rather than using
the unlowered siltype generated via creating a SILType from the field's
vardecl.
Swift SVN r14294
