Also in this is switching to using sysconf instead of sysctlbyname
to determine hardware concurrency, since it's more portable and
also works on OSX/iOS.
Swift SVN r25782
Now if you want to get these dynamic metrics from the runtime all you
need to do is:
1. Configure Swift with -DSWIFT_RUNTIME_ENABLE_DTRACE=YES
2. Run your routine with the command:
sudo dtrace -s ./utils/runtime_statistics.d -c "$MY_COMMAND_LINE"
After your app finishes running, it will dump out the counts. This is a
much more efficient and low maintenance way to get such statistics than
custom instrumenting the code.
Nothing is changed if -DSWIFT_RUNTIME_ENABLE_DTRACE is not set.
Swift SVN r25264
attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
This adds support to build-script and cmake scripts for cross-compiling the host tools in addition to stdlib.
To cross-compile, build-script-impl now accepts --cross-compile-tools-deployment-targets with a space separated list of targets to cross compile host Swift tools for.
For example: $ build-script ...other-args... -- --cross-compile-tools-deployment-targets="iphoneos-arm64 iphoneos-armv7".
When installing cross-compiled tools, it now also merges and runs lipo to produce fat binaries by merging the cross-compiled target architectures.
Swift SVN r24712
The SLPVectorizer is now faster (rdar://problem/19430955): it needs 2.5% of stdlib compile time.
Related radar: rdar://problem/19433841
Swift SVN r24511
This shaves around 5 seconds off the stdlib build if you're using a
release/no-assert LLVM (so around 12.5% of total time if you're also
using a release/no-assert swift, or around 4% of total time if you're
using a debug/assert swift).
The underlying LLVM issue is tracked by rdar://problem/19430955.
I saw no significant reproducible performance loss due to this change.
Resolves rdar://problem/19431821.
Swift SVN r24342
Often times one wants to pass certain flags to swift when building
specific libraries and not others. This has in the past required
manually modifying the cmake system. This new option allows one to use
string regexps based on the module_name of a library to enable and
disable various flags. The way this works is you pass the following into
build-script:
--extra-swift-options="${REGEX1};${FLAGS1_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX2};${FLAGS2_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX3};${FLAGS3_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX4};${FLAGS4_WITH_SEMICOLONS_ESCAPED}"
--extra-swift-options="${REGEX5};${FLAGS5_WITH_SEMICOLONS_ESCAPED}"
Every library that matches REGEPN will have FLAGSN_... appended to their
swift flags. For instance if I did the following:
build-script --extra-swift-options="Swift;-Xfrontend\;-sil-print-pass-name" --extra-swift-options='^Swift$;-Xllvm\;-debug-only=sil-arc-opts" ...
CMake will output the following:
-- Matched 'Swift' to module 'Swift'. Compiling Swift with special flags: -Xfrontend;-sil-print-pass-name
-- Matched '^Swift$' to module 'Swift'. Compiling Swift with special flags: -Xllvm;-debug-only=sil-arc-opts
-- Matched 'Swift' to module 'SwiftExperimental'. Compiling SwiftExperimental with special flags: -Xfrontend;-sil-print-pass-name
-- Matched 'Swift' to module 'SwiftStructures'. Compiling SwiftStructures with special flags: -Xfrontend;-sil-print-pass-name
-- Matched 'Swift' to module 'SwiftStructuresGraphBFS'. Compiling SwiftStructuresGraphBFS with special flags: -Xfrontend;-sil-print-pass-name
stating which regexp was matched, the module it was matched to and the
added flags. This ensures that one only gets matches for what one wants.
Swift SVN r24271
This flag disables the generation of dependency targets that are necessary to accurately rebuild Swift code, but which completely tank the Xcode IDE experience. Since Xcode is primarily useful as a source editor/navigator for the compiler C++ code, and Ninja is a more performant and featureful build system for Swift at this point, provide a mode that generates enough of an Xcode project to edit the Swift compiler source, but which can't build it, as a compromise so we can use Xcode's editor alongside a Ninja build environment.
Swift SVN r24186
This worked in standalone build by creating a directory that never got used but it failed in a non-standalone build.
Fix tracked with Dmitri's help.
Swift SVN r24180
This works around an apparent Xcode bug that prevented the generated
project from properly building static libraries when all of the inputs
were Swift sources. Building static libraries works fine now in Xcode.
Swift SVN r19956
...by pretending to be OS X 10.9. This might remove the need for other
workarounds as well, but I'm not going to go track those down right now.
Swift SVN r13886
The Swift stdlib build uses CMAKE_FORCE_C_COMPILER to cross-compile.
When the compiler is forced cmake does not set the compiler version
variables that llvm's build started checking in llvm commit bf2609e26.
Swift SVN r12311
