Using Clang to compile API notes introduces a dependency on the
underlying Clang, which can cause problems as Clang's support for API
notes evolves. Re-introduce the "-apinotes" driver flag into the Swift
driver to allow us to compile API notes, and use that (rather than
Clang) to precompile API notes for the overlays.
I am going to use the link job for limiting swift lto compile time.
The reason not to use the same variables as LLVM (i.e. LLVM_PARALLEL_LINK_JOBS)
is that Swift since it is compiling more IR may have a larger memory
representation implying less parallel linking jobs than LLVM can be used on
bots.
When I originally committed the LTO code, I tried to match the coding style of
the code right above it that enabled code coverage. Turns out that the code
coverage code did not have a weird coding style and instead just had a bug.
I fixed both of the issues and also enabled the LTO flag on non-Darwin.
Pre-specializations were only used by Onone builds, but were kept inside the standard library dylyb anyways. This commit moves all the pre-specializations into a dedicated Swift module and a dynamic library, which are only used by Onone builds.
This reduces the code size of libswiftCore.dylib by 4%-5%.
This doesn't hit the runtime. I am going to try that in a little bit.
I saw some nice reductions in compile time in the SILOptimizer in the stdlib.
Specifically, we went from spending ~33 seconds in the siloptimizer -> ~23
seconds. There were other improvements as well.
Keep in mind, I have not tested this with debug info, so it may hog all of your
ram due to crazy amounts of debug info. It would be good to try and do what LLVM
does which is to compile with line tables but not full types.
rdar://24717107
Update the paths that we look in for the cmake modules from LLVM which changed
recently on SVN trunk. Check the old paths first, and if that fails, check the
new path. This permits building against either layout.
The Xlinker flags were getting globbed into a single string since
we started adding current/compatibility version arguments to the
linker.
rdar://problem/24622276
The short-term goal here is to get everything compiling and all the tests
passing.
The mid-term goal is to test the performance of a resilient stdlib.
The long-term goal is to make this the default (and only) build mode.
This should be considered EXPERIMENTAL; we can't even build libSwiftCore
successfully yet.
This brings down StdlibUnittest build time to 90 seconds with either
a DebugAssert or a ReleaseAssert compiler.
The new library, StdlibCollectionTests, is only built when running
validation tests.
We don't want references to local symbols within an image to be relocatable, since this increases startup time and causes problems with relative references.
Although the user sets the option using `--sil-verify-all`, various
build scripts refer to the option as `SWIFT_VERIFY_ALL`. Code comments
indicate that this may have been a separate setting at one time.
Remove the misleading comments and unify naming with
`--sil-verify-all` and `SWIFT_SIL_VERIFY_ALL`. This more closely matches what
the option actually does (adds `-Xfrontend -sil-verify-all` to `swiftc`
invocations during the build process).
This patch adds powerpc64le Linux support. While the patch also adds
the matching powerpc64 bits, there are endian issues that need to be
sorted out.
The PowerPC LLVM changes for the swift ABI (eg returning three element
non-homogeneous aggregates) are still in the works, but a simple LLVM
fix to allow those aggregates results in swift passing all but 8
test cases.
The issue is that this was originally done when in-tree builds were the
preferred way of building so LLVM_ENABLE_DOXYGEN would be defined and LLVM would
have found doxygen as well. When one is doing the current preferred standalone
install, the option LLVM_ENABLE_DOXYGEN is not discoverable to the user via an
option with a default argument and the doxygen package is never searched for.
This commit ensures that when building standalone:
1. LLVM_ENABLE_DOXYGEN is defined as an option with a default value of FALSE.
2. The cmake dtrace package is searched for and found.
When we are building standalone, we take these values from LLVM.
At the time this code was originally written, Swift standard
library hasn't been ported to FreeBSD, so we didn't need any
additional library. This is not true anymore, so fix it.
The `use_internal_sdk` flag has been removed from `_add_variant_link_flags` and
`_add_variant_c_compile_flags` in commit
d9bbb6caf0
In four instances where previously FALSE was given as the value for that
parameter, this value has not been removed from the call.
This causes the two functions to try to append flags to FALSE instead of the
respective link_flags and c_compile_flags variables.
