To invoke the front-end on a SIL with whole-module optimizations enabled, execute:
swiftc -frontend myfile.sil
To invoke the front-end on a SIL without whole-module optimizations enabled, add a -primary-file option:
swiftc -frontend -primary-file myfile.sil
To invoke a sil-opt with whole-module optimizations enabled, use the -wmo option:
sil-opt myfile.sil -wmo
This change was need to be able to write SIL unit tests which should be compiled in the WMO mode.
Swift SVN r31862
This feature is required for the implementation of pre-specialization, because one needs to check if a specialized SIL function with a given name exists in the standard library.
Swift SVN r30307
The callback (which is used for creating CG nodes) was lost when deserializing the functions of a vtable.
Fixes rdar://problem/21609902
Swift SVN r29838
Due to inreased use of llvm::make_range in LLVM headers and ADL for
types defined in the swift namespace, some of the LLVM headers started
to trigger ambiguity errors between llvm::make_range and
swift::make_range.
Swift SVN r29700
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
The two ways functions are created currently is via the two
SILModule::getOrCreateFunction(). One of the methods, takes in a raw mangled
name and uses that to create the function. The other takes in a SILDeclRef to
generate the mangled name. Most function emission (besides some thunk creation
functions) goes through the latter. For now we update the map there. This is ok,
since this map will only be used to provide extra verification that guaranteed
self is occuring everywhere that it is supposed to (since constructors and
destructors still have @owned self).
Swift SVN r27240
Previous attempts to update the callgraph explicitly after calls to
linkFunction() weren't completely effective because we can deserialize
deeply and introduce multiple new function bodies in the process.
This gets us a bit closer, but only adds new call graph nodes. It does
not currently add edges for everything that gets deserialized (and this
is not fatal, so it is a step forward).
Swift SVN r27120
This API is more convenient than using the old getOrCreate API, which requires 9 parameters to be provided.
I'm going to use this API in the subsequent commits.
Swift SVN r27097
Before, providing a full SILFunction declaration object with a proper SILType was the only way to link a function. And constructing such a SILFunction declaration by hand using low-level SIL APIs is very annoying and requires a lot of code to be written. This new linkFunction API allows for a lookup using SILDeclRef and essentially performs linking of a SILFunction by its mangled name (assuming this name is unique), which is much easier to invoke. The new API is useful, e.g. when you need to link a well-known function from a standard library.
Swift SVN r26252
This will have an effect on inlining into thunks.
Currently this flag is set for witness thunks and thunks from function signature optimization.
No change in code generation, yet.
Swift SVN r24998
Write up a requireABICompatibleFunctionTypes check to make sure two function types share the same ABI. The real target here is to be able to apply this to vtable entries in order to uncover variance bugs like rdar://problem/19321484, but convert_function is a convenient testbed.
Swift SVN r24666
The underlying problem is that e.g. even if a method is private but its class is public, the method can be referenced from another module - from the vtable of a derived class.
So far we handled this by setting the SILLinkage of such methods according to the visibility of the class. But this prevented dead method elimination.
Now I set the SILLinkage according to the visibility of the method. This enables dead method elimination, but it requires the following:
1) Still set the linkage in llvm so that it can be referenced from outside.
2) If the method is dead and eliminated, create a stub for it (which calls swift_reportMissingMethod).
Swift SVN r23889
SILMetadata is the base class with a single enum member (MDKind).
SILBranchNode is the derived class with additional members:
unsigned NumOperands
an array of uint32_t
A static member function SILBranchNode::get is implemented to get or create
SILBranchNode. All SILMetadata created are uniqued and saved in SILModule's
member variable:
llvm::FoldingSet<SILMetadata> Metadatas
Usage of SILMetadta by SILInstruction is captured in SILModule's member variable:
llvm::DenseMap<const SILInstruction *, SILMetadata *> MetadataStore
This is similar to LLVM's Metadata. Another option is to add a SILMetadata* to
SILInstruction. The disadvantage is the waste of space when we don't have PGO on.
This commit also enables parsing and printing of SILMetadata.
We add keyword sil_metadata to define SILMetadata:
sil_metadata !0 = {"branch_weights", 3, 5}
For parsing, we add a map in SILModule
llvm::DenseMap<unsigned, SILMetadata *> NumberedMetadata
that maps from ID to SILMetadata* to help matching usage of "!id" in SILFunction
with definition of "!id" in sil_metadata section.
For printing, we assign IDs to SILMetadata at SILModule scope, we then pass in
an optional argument of
llvm::DenseMap<const SILMetadata *, unsigned> *MetadataMap
to SILFunction::print in order to get the ID of SILMetadata used in
SILInstruction.
Post-commit review will be appreciated.
rdar://18269754
Swift SVN r23713
This should have been done a long time ago since SILOptions are options that
should be able to effect everything SIL related. In this case I just want to
pass in a flag on the SILModule to enable +0 self. By putting it on the
SILModule I can conveniently check it in SILFunctionType without exposing any
internal state from SILFunctionType.cpp.
Swift SVN r23647
This is controlled by a new isWholeModule() attribute in SILModule.
It gives about 9% code size reduction on the benchmark executables.
For test-suite reasons it is currently not done for the stdlib.
Swift SVN r22491
This will be used for parsing sil generated from stdlib. We will ignore
the AST decls and instead import them from the module.
rdar://17979145
Swift SVN r22367
This prevented dead function removal of inlined dead functions. Beside the stdlib it's mostly
an issue of SIL size (and therefore compiletime), because llvm did remove such functions anyway.
Swift SVN r22301
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
info for them and generally clean up the inline scope handling a bit.
Fix the debug scope handling for all clients of SILCloner, especially
the SIL-level spezializers and inliners.
This also adds a ton of additional assertions that will ensure that
future optimization passes won't mess with the debug info in a way that
could confuse the LLVM backend.
Swift SVN r18984
The deserializer holds a reference to the deserialized SILFunction, which
prevents Dead Function Elimination from erasing them.
We have a tradeoff on how often we should clean up the unused deserialized
SILFunctions. If we clean up at every optimization iteration, we may
end up deserializing the same SILFunction multiple times. For now, we clean
up only after we are done with the optimization iteration.
rdar://17046033
Swift SVN r18697
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
This is important since it enables one to analyze the type of the
conformance that the witness table implements which may be different
than the original type. This follows the precedent where we return the
Substitutions from the protocol conformance tree traversal.
Swift SVN r17220
When deserializing, the serialized sil loader attempts to first lookup
from its SILModule the witness table to attempt to grab a witness table
declaration. Before this patch if the SILModule could not find it, it
would attempt to deserialize it. In certain edge cases this would cause
us to attempt to deserialize a function definition which violates the
invariant that that should never happen.
This patch adds an argument to SILModule::lookUpWitnessTable that
enables you to turn off the lazy deserialization behavior. The default
argument gives the current behavior which should be used everywhere
except for the deserializer.
Swift SVN r16740
This enables us to get around timing issues when we create a SILModule before we
have finished loading all Swift Modules.
This manifested itself in sil-opt where we were unable to deserialize from the
standard library when optimizing a separate *.sil file.
Swift SVN r15670
