This was once used in lldb but no longer is. I'm cannot find any other
users, so I'm removing it as a small part of cleaning up and simplifying
the SIL linking process.
Use malloc/free for allocating/freeing SIL instructions instead of using the BumpPtrAllocator. This allows for memory reuse and significantly reduces the memory footprint of the compiler.
For example, a peak memory usage during a compilation of the standard library and StdlibUnitTest is reduced by 25%-30%. The performance of the compiler seems to be not affected by this change, i.e. no slowdown is measured.
The use-after-free issues reported by build bots are fixed now.
rdar://23303031
Modeling nonescaping captures as @inout parameters is wrong, because captures are allowed to share state, unlike 'inout' parameters, which are allowed to assume to some degree that there are no aliases during the parameter's scope. To model this, introduce a new @inout_aliasable parameter convention to indicate an indirect parameter that can be written to, not only by the current function, but by well-typed, well-synchronized aliasing accesses too. (This is unrelated to our discussions of adding a "type-unsafe-aliasable" annotation to pointer_to_address to allow for safe pointer punning.)
This commit adds a hook that allows passes, analysis or data structures that can
be registered as receivers of delete notifications to decide if they want to
receive notifications All of the analysis and the currently executing passes are
automatically registered to receive notifications and this hook is useful in
reducing the runtime overhead. With this change the only analysis that accepts
notifications is alias analysis.
This centralizes the entrypoints for creating SILFunctions. Creating a
SILFunction is intimately tied to a specific SILModule, so it makes sense to
either centralize the creation on SILModule or SILFunction. Since a SILFunction
is in a SILModule, it seems more natural to put it on SILModule.
I purposely created a new override on SILMod that exactly matches the signature
of SILFunction::create so that beyond the extra indirection through SILMod, this
change should be NFC. We can refactor individual cases in later iterations of
refactoring.
This commit adds the basic support for delete notification handlers. The SIL
Module is notified every time an instruction is deleted. The module will forward
notification messages to users who ask to be notified. The motivation for this
work is described in the upcoming commit to OptimizerDesign.md.
This reverts commit bf2fdb6764.
One of the build bots reported a malloc/free error, while other bots had successful builds. It could indicate a non-deterministic failure.
Preventively revert this patch as it is the most likely cause of these issues.
rdar://23611346
Use malloc/free for allocating/freeing SIL instructions instead of using the BumpPtrAllocator. This allows for memory reuse and significantly reduces the memory footprint of the compiler.
For example, a peak memory usage during a compilation of the standard library and StdlibUnitTest is reduced by 25%-30%. The performance of the compiler seems to be not affected by this change, i.e. no slowdown is measured.
The use-after-free issue reported by build bots is fixed now.
rdar://23303031
Use malloc/free for allocating/freeing SIL instructions instead of using the BumpPtrAllocator. This allows for memory reuse and significantly reduces the memory footprint of the compiler.
For example, a peak memory usage during a compilation of the standard library and StdlibUnitTest is reduced by 25%-30%. The performance of the compiler seems to be not affected by this change, i.e. no slowdown is measured.
rdar://23303031
This re-applies commit r31763 with a change to the predicate we
use for determining the linkage of a definition. It turns out we
could have definitions with a Clang body that were still public,
so instead of checking for a Clang body just check if the Clang
declaration is externally visible or not.
Swift SVN r31777
If an external SIL function has a Clang-generated body, I think this
means we have a static function, and we want to use Shared linkage,
not Public.
Add a new flag to SILFunction for this and plumb it through to
appease assertions from SILVerifier.
Swift SVN r31763
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 isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
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
When debugging a compiler, using -debug would crash the compiler on some witness_method instructions, because sometimes their conformances are empty (e.g. if the type being looked-up is an archetype or an existential).
Swift SVN r27325
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 is only used by SILModule but is not integral to a SILModule so it makes
sense to have it in its own file. It keeps SILModule.cpp more focused. We still
keep it in a private header though since it is only meant to be used by
SILModule.cpp.
Swift SVN r25985
For better consistency with other address-only instruction variants, and to open the door to new exciting existential representations (such as a refcounted boxed representation for ErrorType).
Swift SVN r25902
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
1. Eliminate unused variable warnings.
2. Change field names to match capitalization of the rest of the field names in the file.
3. Change method names to match rest of the file.
4. Change get,set method for a field to match the field type.
Swift SVN r24501
This bug would manifest itself only when a module with multiple files is being compiled and some derived classes are defined in a file different from the one where a base class is defined. Due to this bug a method from a base class would be invoked instead of a method from a derived class when devirtualization was performed. The problem was that we were saying that failure to link a vtable is equivalent to failure to find a function in the vtable itself in which case we would go up to the parent vtable.
To avoid this kind of bug in the future a test case with a module consisting of multiple files is added to the test suite.
rdar://19334105 rdar://19337398
Swift SVN r24264
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
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 allows making global addressors fragile (They use globalinit_{token,func} for initialization of globals).
It has no noticable performance impact on our benchmarks, but it removes an ugly hack which explicitly
prevented addressors from being fragile.
Swift SVN r22812
This allows making global addressors fragile (They use globalinit_{token,func} for initialization of globals).
It has no noticable performance impact on our benchmarks, but it removes an ugly hack which explicitly
prevented addressors from being fragile.
Swift SVN r22795
