Commit Graph

111 Commits

Author SHA1 Message Date
swift-ci
395487153c Merge remote-tracking branch 'origin/main' into rebranch 2022-12-14 05:34:35 -08:00
Jonathan Grynspan
c889270a38 Remove lookupSymbol() and have all callers use SymbolInfo::lookup() instead (#62552) 2022-12-14 08:33:32 -05:00
eeckstein
12c9266d5c Revert "Revert "fix wrong attribute ordering in the runtime"" 2022-12-01 10:41:04 +01:00
Ben Barham
a54b15df87 Revert "fix wrong attribute ordering in the runtime"
This reverts commit 0494db062a as it was a
workaround for a Clang bug that is now fixed (see
https://reviews.llvm.org/D137979).
2022-11-29 10:56:01 -08:00
Mike Ash
b9391c03e5 Merge pull request #61794 from mikeash/retain-stack-frames
[Runtime] Eliminate stack frames in swift_retain and swift_bridgeObjectRetain on ARM64.
2022-11-08 15:32:55 -05:00
Erik Eckstein
0494db062a fix wrong attribute ordering in the runtime
This is required to a clang change. Attribute need to be in a certain order when building with a newer clang.

This fix might be replaced by something better, e.g. https://github.com/apple/swift/pull/61476
2022-11-08 09:35:44 +01:00
Mike Ash
724a9a7da4 [Runtime] Eliminate stack frames in swift_retain and swift_bridgeObjectRetain on ARM64.
Rearrange the slow paths a bit to make them tail calls, which allows the compiler to emit these functions without frames.

Clang is happy to emit frameless functions on ARM64 if no stack space is needed on all execution paths. However, when there's a fast path which doesn't need stack space, and a slow path which does, clang emits code that pushes a stack frame and then decides which path to take. This is fine, but it means we're paying more than we'd like to on the fast path.

We can work around that by manually outlining the slow path, and ensuring that it's invoked with a tail call. Then the original function doesn't need a stack frame on any path and clang omits the stack frame.

We tweak RefCounts::increment to return the object it's being called on, which allows `swift_retain` to tail-call it. We manually outline the objc_retain call in swift_bridgeObjectRetain, which allows the swift_retain path to be frameless.

rdar://101764509
2022-11-07 15:38:14 -05:00
Alex Lorenz
a24ebeaa51 [interop][SwiftToCxx] install _SwiftCxxInteroperability.h header as part of compiler build, not stdlib
The _SwiftCxxInteroperability.h is too tightly coupled to the compiler right now and should not be shipped with the standard library. In the future it could be moved back to the standard library.
2022-09-28 16:14:33 -07:00
Anthony Latsis
c731089068 Gardening: Migrate stdlib sources to GH issues 2022-09-26 06:30:49 +03:00
Alex Lorenz
1d6d3ff970 [interop][SwiftToCxx] trap on moves of Swift values for now
Move support will be added later
2022-09-21 06:59:29 -07:00
Egor Zhdan
84a1ffcb33 [Shims] Include SwiftShims headers without ../
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```

This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
       ^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
       ^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
2022-09-14 11:14:50 +01:00