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
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).
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.
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
(Also, be careful only to do this for private link libraries that are
actually targets.)
<rdar://problem/23621157>
libswiftStdlibStubs.a is meant to be an intermediate built product
that's pulled into libswiftCore.a, not its own thing. Add a post-build
step for libswiftCore.a to pull all the object files into it from
libswiftStdlibStubs.a.
<rdar://problem/23621157>
