As per 7b19531291
CMake 4.0 does not pass `-sdk` to compiler invocations if the user does
not provide `CMAKE_OSX_SYSROOT` -- this in turn causes failures in
linking.
Addresses rdar://163672815
This is currently disabled by default. Building the client library can be enabled with the CMake option SWIFT_BUILD_CLIENT_RETAIN_RELEASE, and using the library can be enabled with the flags -Xfrontend -enable-client-retain-release.
To improve retain/release performance, we build a static library containing optimized implementations of the fast paths of swift_retain, swift_release, and the corresponding bridgeObject functions. This avoids going through a stub to make a cross-library call.
IRGen gains awareness of these new functions and emits calls to them when the functionality is enabled and the target supports them. Two options are added to force use of them on or off: -enable-client-retain-release and -disable-client-retain-release. When enabled, the compiler auto-links the static library containing the implementations.
The new calls also use LLVM's preserve_most calling convention. Since retain/release doesn't need a large number of scratch registers, this is mostly harmless for the implementation, while allowing callers to improve code size and performance by spilling fewer registers around refcounting calls. (Experiments with an even more aggressive calling convention preserving x2 and up showed an insignificant savings in code size, so preserve_most seems to be a good middle ground.)
Since the implementations are embedded into client binaries, any change in the runtime's refcounting implementation needs to stay compatible with this new fast path implementation. This is ensured by having the implementation use a runtime-provided mask to check whether it can proceed into its fast path. The mask is provided as the address of the absolute symbol _swift_retainRelease_slowpath_mask_v1. If that mask ANDed with the object's current refcount field is non-zero, then we take the slow path. A future runtime that changes the refcounting implementation can adjust this mask to match, or set the mask to all 1s to disable the old embedded fast path entirely (as long as the new representation never uses 0 as a valid refcount field value).
As part of this work, the overall approach for bridgeObjectRetain is changed slightly. Previously, it would mask off the spare bits from the native pointer and then call through to swift_retain. This either lost the spare bits in the return value (when tail calling swift_retain) which is problematic since it's supposed to return its parameter, or it required pushing a stack frame which is inefficient. Now, swift_retain takes on the responsibility of masking off spare bits from the parameter and preserving them in the return value. This is a trivial addition to the fast path (just a quick mask and an extra register for saving the original value) and makes bridgeObjectRetain quite a bit more efficient when implemented correctly to return the exact value it was passed.
The runtime's implementations of swift_retain/release are now also marked as preserve_most so that they can be tail called from the client library. preserve_most is compatible with callers expecting the standard calling convention so this doesn't break any existing clients. Some ugly tricks were needed to prevent the compiler from creating unnecessary stack frames with the new calling convention. Avert your eyes.
To allow back deployment, the runtime now has aliases for these functions called swift_retain_preservemost and swift_release_preservemost. The client library brings weak definitions of these functions that save the extra registers and call through to swift_retain/release. This allows them to work correctly on older runtimes, with a small performance penalty, while still running at full speed on runtimes that have the new preservemost symbols.
Although this is only supported on Darwin at the moment, it shouldn't be too much work to adapt it to other ARM64 targets. We need to ensure the assembly plays nice with the other platforms' assemblers, and make sure the implementation is correct for the non-ObjC-interop case.
rdar://122595871
Piggyback the addition of a flag to specify the path of the
CMakeConfig.h header needed to compile Observation (needed when
consuming SwiftCore through the fine module), and the declaration of
SwiftShims as a dependency.
Addresses rdar://149241712
To make this work:
* expose SwiftCMakeConfig.h from the Core build
system, to support scenarios in which the downstream Distributed build
is leveraging the config files generated by CMake itself.
* adjust how SwiftShims is defined in `FindSwiftCore.cmake`, so that the
shims are found from C++ and that we don't get redefinition errors
when multiple module maps are in the search paths.
Fixes#83449
Addresses rdar://149241603, rdar://157165530
Currently we are using the same versions we use to build compiler and
standard library. This is an unnecessary coupling especially when
testing the generation of backdeployed executables for macOS -- here
we have interest in being able to run the tests on previous OSes, not
the compiler itself.
To support this, add new `--darwin-test-deployment-version-<platform>`
flags to build-script, which by default take the same value as the
matching `--darwin-deployment-version-<platform>` ones.
Addresses rdar://156724078
We use C++17 for the Swift compiler and IRGen uses the sized
deallocation for releasing memory it creates with over-allocation. That
triggers ASAN warnings due to the mismatched
`operator new`/`operator delete`.
Take the chance to match the flags used in the existing build system,
and adjust code ownership to cover the file I added to track the
experimental flags for the overlays.
Addresses rdar://155882420
...when using `--enable-new-runtime-build`
When building changes incrementally the runtime build system is not
invoked -- the configure and build steps generated by `ExternalProject_Add`
are effectively triggered only if the `CMAKE_ARGS` argument changes.
We should instead delegate to the the Runtime build system to figure out
if it needs to regenerate the `build.ninja` file and/or trigger any
rebuild -- this can be done by passing `BUILD_ALWAYS 1` to
`ExternalProject_Add`.
Addresses rdar://155559208
Ideally this would also update the `--version` output to be overridden
by `SWIFT_TOOLCHAIN_VERSION`, but unfortunately various tools rely on
the current format (eg. swift-build).
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
To work-around #80059, we need to stop return address signing and
opt-out of BTCFI enforcement via enabling a platform linker option.
We don't want to completely undo the BTCFI work in the rare case that
we later figure out how to properly address the above issue, or allow
users who might want to benefit from BTCFI enforcement and won't use
Concurrency. To do this, condition the existing BTCFI flag enforcement
into a configuration option that defaults to off for now.
Because the new swift-driver needs to "know" whether the frontend is
configured to opt-out or not, and since the new driver communicates with
the frontend via the target info JSON to begin with, we add a field
that emits the build flavor to signal the right behavior.
The CMake compiler checks depend on StringProcessing being implemented.
The old build system may not have rebuilt the module, which will cause
the compiler check to fail. Disable the CMake compiler verification.
WASI with Embedded Swift provides WASI-libc and libc++ headers necessary to build the `_Concurrency` module for Wasm. We now add `wasm32-unknown-wasip1-wasm` triple to `EMBEDDED_STDLIB_TARGET_TRIPLES` when `SWIFT_WASI_SYSROOT_PATH` is set, which builds the necessary stdlib slice.
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
Adding `SWIFT_ENABLE_SWIFT_IN_SWIFT` option to enable or disable the
parts of Swift that require a Swift compiler to build. This is meant for
bootstrapping compilers on new platforms and is not guaranteed to result
in a compiler that will pass the test suite.
This option is on by default so that folks won't forget.
If the option is off, the resulting compiler does not include the Swift
optimizer sources in SwiftCompilerSources nor does the resulting
compiler have swift macro support.
This patch adds initial support for Emscripten SDK alongside the existing
support for WASI SDK. This is a first step towards building a part of
Swift compiler for Emscripten target (which will be used to build LLDB
with Swift to WebAssembly target).
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
Pass the minimum deployment target into the builds when appropriate.
Fixes the clang warning about mismatched minimum deployment targets
passed via flag and compiler target.
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
For C/CXX targets, sanitizer options are set by 'CMAKE_{C|CXX}_FLAGS' in
HandleLLVMComfig.cmake. However for Swift targets, they are set for each
target. That caused some mismatch issues. Instead set them globally for
Swift targets too.
rdar://142516855
Fixed an issue in the convenience wrapper that resulted in building all
copies of the standard library for the default compiler architecture
instead of the desired architecture. To fix this, we pull the desired
target triple and deployment target from the existing variables and pass
that into the CMake invocation.
This will support configurations where ninja is not the search path,
and will avoid problems that can arise from the stdlib build detecting
and using a different generator.
Addresses rdar://142268599
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
