Hoist alloc_stack instructions of 'generic' or resilient type to the entry
block. At the same time also perform a very simple stack coloring analysis.
This does not use a true liveness-analysis yet but rather employs some simple
conservative checks to see whether the live ranges of two alloc_stacks might
interfere.
AllocStackHoisting is an IRGen SIL pass. This allows for using IRGen's type
lowering information. Furthermore, hoisting and merging the alloc_stack
instructions this late does not interfere with SIL optimizations because the
resulting SIL never gets serialized.
This pipeline is run as part of IRGen and has access to the IRGenModule.
Passes that run as part of this pipeline can query for the IRGenModule.
We will use it for the AllocStackHoisting pass. It wants to know if a type is of
non-fixed size.
To break the cyclic dependency between IRGen -> SILOptimizer -> IRGen that would
arise from the SILPassManager having to know about the createIRGENPASS()
function IRGen passes instead of exposing this function dynamically have to add
themselves to the pass manager.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
There is no need to keep SILModules around after IRGen has generated LLVM IR from them.
This reduces the compiler memory usage during LLVM code-generation and optimization phases roughly by 15%-20%.
The original support for embedded bitcode used appending linkage for the
magic internal variables that hold the bitcode and command line options,
but that private linkage is a better fit. The only real reason for
appending linkage was to prevent those variables from being optimized away.
r269706 limits the use of appending linkage so that it cannot be used for
those variables, so this switches to use private linkage and keep the
variables alive with llvm.compiler.used. This is basically copied from
clang r269679. rdar://problem/28685198.
As of the swift-3.1-branch versions of Clang/LLVM, embedded bitcode is now
working well enough that the tests can be reenabled. rdar://problem/26247134
The existing code was not handling the linkage of global aliases in LLVM modules. This resulted in linking errors in certain cases, because the LLVM backend would remove some type metadata in scope of a dead code elimination.
Fixes rdar://27245620
This flag switches the "effective language version" of the compiler,
at least to any version supported (as of this change: "3" or "3.0").
At the moment nothing uses it except the language version build
configuration statements (#if swift(...)) and various other places
that report, encode, or otherwise check version numbers.
In the future, it's intended as scaffolding for backwards compatibility.
Fixes SR-2582
Ensure they get emitted at the end of the job by the dispatcher, and
also use a proper mangling and shared linkage for these symbols so
that if multiple threads emit the same descriptor it gets merged.
The new tests attempt to exercise these scenarios.
Fixes <rdar://problem/27906876>.
Emit a 16-bit constant that tracks the version of the reflection
metadata emitted into binaries. This can be used to cross-check
what is supported by the SwiftRemoteMirror library with the new
version API.
rdar://problem/27251582
We would previously default to ELF. Although the behaviur here is preserved, we
are explicitly mapping the section/segment name based on the output object
format. NFC.
"Sanitizer Coverage" with a new flag ``-sanitize-coverage=``. This
flag is analogous to Clang's ``-fsanitize-coverage=``.
This instrumentation currently requires ASan or TSan to be enabled
because the module pass created by ``createSanitizerCoverageModulePass()``
inserts calls into functions found in compiler-rt's "sanitizer_common".
"sanitizer_common" is not shipped as an individual library but instead
exists in several of the sanitizer runtime libraries so we have to
link with one of them to avoid linking errors.
The rationale between adding this feature is to allow experimentation
with libFuzzer which currently relies on "Sanitizer Coverage"
instrumentation.
Clang IR-generation can fail. When it does this, it destroys the
module. Previously, we were blithely assuming this couldn't happen,
and so we would crash on the deallocated module. Delay the
finalization of the Clang code generator until our own module
finalization, which is a more appropriate place for it anyway,
and then just bail out of the last few steps if Clang fails.
It's like LLVM's MergeFunctions pass, except that it can also merge functions which differ by some constants.
The intention is to merge specialized functions which only differ by metadata lookups. But it can also merge other types of functions.
It gives ~7% code size reducation for the stdlib.
There are still some open TODOs, e.g. to share common code with LLVM's MergeFunctions pass (currently much code is just copied).
Rather than collection nominal type and extension decls and emit
reflection metadata records in one go, we can emit them as they
are encountered and instead collection builtin types referenced
by those at the end.
In order to perform layout, the remote mirrors library needs to know
about the size, alignment and extra inhabitants of builtin types.
Ideally we would emit a reflection info section in libswiftRuntime.o,
but in the meantime just duplicate builtin type metadata for all
builtin types referenced from the current module instead.
In practice only the stdlib and a handful of overlays like the SIMD
overlay use builtin types, and only a few at a time.
Tested manually by running swift-reflection-tool on the standard
library -- I'll add automated tests by using -parse-stdlib to
reference Builtin types in a subsequent patch that adds more layout
logic.
NFC if -enable-reflection-metadata is off.
Currently IRGen stores hashes of the bitcode generated by swift in object files.
This is then used to reduce compile time by not re-codegening if a subsequent
compilation yields a bit code with the same hash.
This is good for users and general compilation, but can result in confusion when
attempting to measure the "real" compile time of the compiler.
By default it is off.
