`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
The `AttrBuilder` API was changed in llvm/llvm-project
d2cc6c2d0c2f8a6e272110416a3fd579ed5a3ac1 to now take a `LLVMContext &`
as part of its constructor. Update uses to pass one in.
This is an incremental improvement of the debug info at a
(hop_to_executor) suspend site.
Before this patch the debug info at the call site would use the
`__swift_suspend_point` function name as the current function after
coro lowering has inlined the thunk.
The proper fix is to rewire the debug info such that the thunk name is
never mentioned rather the current function that suspend site sits in is
used.
Until I have figured out how to do that using the current function name
instead of `__swift_suspend_point` for the thunk is an incremental
improvement in the debug information consumers can observe.
rdar://90859530
Improvement upon #41645 to emit the async suspend dispatch thunk's debug
info with the `linkageName` of the containing function of the async
await.
rdar://88579737
This is an incremental improvement of the debug info at a suspend apply site.
Before this patch the debug info at the call site would use the
`__swift_suspend_dispatch` function name as the current function after
coro lowering has inlined the thunk.
The proper fix is to rewire the debug info such that the thunk name is
never mentioned rather the current function that suspend site sits in is
used.
Until I have figured out how to do that using the current function name
instead of `__swift_suspend_dispatch.5` for the thunk is an incremental
improvement in the debug information consumers can observe.
rdar://88579737
The special convention currently means three things:
1. There is no async FP symbol for the function. Calls should go directly
to the function symbol, and an async context of fixed static size should be
allocated. This is mandatory for calling runtime-provided async functions.
2. The callee context should be allocated but not initialized. The main
context pointer passed should be the caller's context, and the continuation
function pointer and callee context should be passed as separate arguments.
The function will resume the continuation function pointer with the caller's
context. This is a micro-optimization appropriate for functions that are
expected to frequently return immediately; other functions shouldn't bother.
3. Generic arguments should be suppressed. This is a microoptimization for
certain specific runtime functions where we happen to know that the runtime
already stores the appropriate information internally. Other functions
probably don't want this.
Obviously, these different treatments should be split into different
predicates so that functions can opt in to different subsets of them.
I've also set the code up so that runtime functions can more easily
request a specific static async context size. Previously, it was a
confusingly embedded assumption that the static context size was always
exactly two pointers more than the header.
There are three major changes here:
1. The addition of "SILFunctionTypeRepresentation::CXXMethod".
2. C++ methods are imported with their members *last*. Then the arguments are switched when emitting the IR for an application of the function.
3. Clang decls are now marked as foreign witnesses.
These are all steps towards being able to have C++ protocol conformance.
This reverts commit d27e6e1e46, reversing
changes made to f2e85a2b1f.
It causes an execution time failure in
`Interpreter/struct_extra_inhabitants.swift` with
```
ninja -C swift-macosx-x86_64 check-swift-optimize
```
rdar://86054209
The functions in llvm-project `AttributeList` have been
renamed/refactored to help remove uses of `AttributeList::*Index`.
Update to use these new functions where possible. There's one use of
`AttrIndex` remaining as `replaceAttributeTypeAtIndex` still takes the
index and there is no `param` equivalent. We could add one locally, but
presumably that will be added eventually.
This reverts commit 5ebb1b2fc6, reversing
changes made to 76260c2235.
This commit causes compiler crashes when using protocol composition
types involving objc.
Repo:
```
import Foundation
public class SomeObject : NSObject {}
public protocol ProtoA{}
public protocol SomeProtoType { }
public typealias Composition = SomeObject & SomeProtoType
public struct Thing<T: ProtoA> {
let a: Composition
let b: T
init(a: Composition,
b: T
) {
self.a = a
self.b = b
}
}
$ swiftc -c Repo.swift -O
```
While looking at this issue I noticed that it is not correct to use a
ScalarEntry of ObjCReference (or other ScalarKind::XXXReference) for
`AddressOnly##Name##ClassExistentialTypeInfo` types. These should be
calling the IGF.emit##Name##Destroy(addr, Refcounting); functions not
objc_release.
It is probably best to use the macro facilities in a similar fashion like
lib/IRGen/GenExistential.cpp does.
rdar://85269025
Summary:
As part of SR-14273, the type layout infrastructure needs to be able to be able
to differentiate between types of scalars so it knows how to release/retain
appropriately. Right now, for example, to destroy a scalar, it blindly calls
into typeInfo's irgen functions which means it's not able to generate any of
the needed information for itself.
This patch adds a field to ScalarTypeLayout to allow them to know what kind of
reference they are and strings through the machinery to provide the information
to set it.
This also moves ScalarTypeLayout::destroy to use the new information.
Test Plan: ninja check-swift
Reviewers: mren, #pika_compiler
Reviewed By: mren
Subscribers: apl, phabricatorlinter
Differential Revision: https://phabricator.intern.facebook.com/D30983093
Tasks: T100580959
Tags: swift-adoption
Signature: 30983093:1632340205:3bdd3218ae86ad6b3d199cc1b504a625e3650ec0
This is to deal with the fact that LLVM's coroutine can't handle instructions
with side-effects well that are inserted before the coro.begin.
rdar://81113950
Changes the task, taskGroup, asyncLet wait funtion call ABIs.
To reduce code size pass the context parameters and resumption function
as arguments to the wait function.
This means that the suspend point does not need to store parent context
and resumption to the suspend point's context.
```
void swift_task_future_wait_throwing(
OpaqueValue * result,
SWIFT_ASYNC_CONTEXT AsyncContext *callerContext,
AsyncTask *task,
ThrowingTaskFutureWaitContinuationFunction *resume,
AsyncContext *callContext);
```
The runtime passes the caller context to the resume entry point saving
the load of the parent context in the resumption function.
This patch adds a `Metadata *` field to `GroupImpl`. The await entry
pointer no longer pass the metadata pointer and there is a path through
the runtime where the task future is no longer available.
As part of bringup, specifically in order to support storing the size of
the async context as the first entry in the thick context, the
optimization that allows the partial application of a single refcounted
object to avoid the allocation of a thick context was disabled.
Now that we have async function pointers for partial application
forwarders, that rationale is moot, so, here, the optimization is
restored.
rdar://76372871
Previously, because partial apply forwarders for async functions were
not themselves fully-fledged async functions, they were not able to
handle dynamic functions. Specifically, the reason was that it was not
possible to produce an async function pointer for the partial apply
forwarder because the size to be used was not knowable.
Thanks to https://github.com/apple/swift/pull/36700, that cause has been
eliminated. With it, partial apply forwarders are fully-fledged async
functions and in particular have their own async function pointers.
Consequently, it is again possible for these partial apply forwarders to
handle non-constant function pointers.
Here, that behavior is restored, by way of reverting part of
ee63777332 while preserving the ABI it
introduced.
rdar://76122027
External async functions pointers can't be used to clone the async
context size from.
Future improvement: reinstate the previous optimization of reusing the
context.
rdar://76029017
The current code generation will emit an autibsp after adjusting the
stack pointe for the tail call. If callee and caller argument area does
not match this would fail.
Most of the async runtime functions have been changed to not
expect the task and executor to be passed in. When knowing the
task and executor is necessary, there are runtime functions
available to recover them.
The biggest change I had to make to a runtime function signature
was to swift_task_switch, which has been altered to expect to be
passed the context and resumption function instead of requiring
the caller to park the task. This has the pleasant consequence
of allowing the implementation to very quickly turn around when
it recognizes that the current executor is satisfactory. It does
mean that on arm64e we have to sign the continuation function
pointer as an argument and then potentially resign it when
assigning into the task's resume slot.
rdar://70546948
Previously, thick async functions were represented sometimes as a pair
of (AsyncFunctionPointer, nullptr)--when the thick function was produced
via a thin_to_thick_function, e.g.--and sometimes as a pair of
(FunctionPointer, ThickContext)--when the thick function was produced by
a partial_apply--with the size stored in the slot of the ThickContext.
That optimized for the wrong case: partial applies of dynamic async
functions; in that case, there is no appropriate AsyncFunctionPointer to
form when lowering the partial_apply instruction. The far more common
case is to know exactly which function is being partially applied. In
that case, we can form the appropriate AsyncFunctionPointer.
Furthermore, the previous representation made calling a thick function
more complex: it was always necessary to check whether the context was
in fact null and then proceed along two different paths depending.
Here, that behavior is corrected by creating a thunk in a mandatory
IRGen SIL pass in the case that the function that is being partially
applied is dynamic. That new thunk is then partially applied in place
of the original partial_apply of the dynamic function.
The `coro.end.async` intrinsic allow specifying a function that is to be
tail-called as the last thing before returning.
LLVM lowering will inline the `must-tail-call` function argument to
`coro.end.async`. This `must-tail-call` function can contain a
`musttail` call.
```
define @my_must_tail_call_func(void (*)(i64) %fnptr, i64 %args) {
musttail call void %fnptr(i64 %args)
ret void
}
define @async_func() {
...
coro.end.async(..., @my_must_tail_call_func, %return_continuation, i64 %args)
unreachable
}
```
First, just call an async -> T function instead of forcing the caller
to piece together which case we're in and perform its own copy. This
ensures that the task is actually kept alive properly.
Second, now that we no longer implicitly depend on the waiting tasks
being run synchronously, go ahead and schedule them to run on the
global executor.
This solves some problems which were blocking the work on TLS-ifying
the task/executor state.
This is conditional on UseAsyncLowering and in the future should also be
conditional on `clangTargetInfo.isSwiftAsyncCCSupported()` once that
support is merged.
Update tests to work either with swiftcc or swifttailcc.
LLVM does type based analysis on sret storage types. This is a problem
with non-fixed types whose storage type does not contain the non-fixed
part.
rdar://73778591
Compiler:
- Add `Forward` and `Reverse` to `DifferentiabilityKind`.
- Expand `DifferentiabilityMask` in `ExtInfo` to 3 bits so that it now holds all 4 cases of `DifferentiabilityKind`.
- Parse `@differentiable(reverse)` and `@differentiable(_forward)` declaration attributes and type attributes.
- Emit a warning for `@differentiable` without `reverse`.
- Emit an error for `@differentiable(_forward)`.
- Rename `@differentiable(linear)` to `@differentiable(_linear)`.
- Make `@differentiable(reverse)` type lowering go through today's `@differentiable` code path. We will specialize it to reverse-mode in a follow-up patch.
ABI:
- Add `Forward` and `Reverse` to `FunctionMetadataDifferentiabilityKind`.
- Extend `TargetFunctionTypeFlags` by 1 bit to store the highest bit of differentiability kind (linear). Note that there is a 2-bit gap in `DifferentiabilityMask` which is reserved for `AsyncMask` and `ConcurrentMask`; `AsyncMask` is ABI-stable so we cannot change that.
_Differentiation module:
- Replace all occurrences of `@differentiable` with `@differentiable(reverse)`.
- Delete `_transpose(of:)`.
Resolves rdar://69980056.
In __swift_async_resume_project_context, the context is stored into the
extended frame. On arm64e, it is signed first. Previously, that signed
context was returned fro the function. That resulted in code like
pacda x16, x10
str x16, [x9]
ldr x9, [x16, #0x48]
where the context is signed (pacda), stored into the extended frame
(str) and then an attempt is made to load from the signed context (ldr).
Here, the unsigned context is returned from the function.
* Adds support for generating code that uses swiftasync parameter lowering.
* Currently only arm64's llvm lowering supports the swift_async_context_addr intrinsic.
* Add arm64e pointer signing of updated swift_async_context_addr.
This commit needs the PR llvm-project#2291.
* [runtime] unittests should use just-built compiler if the runtime did
This will start to matter with the introduction of usage of swiftasync parameters which only very recent compilers support.
rdar://71499498
Previously, swift_suspend_dispatch was passed a pointer to a function
and createAsyncDispatchFn was passed a FunctionPointer. The latter
constructed a new FunctionPointer using the passed-in function pointer
as the value, because the value inside the FunctionPointer was a value
in a different function.
That worked fine on platforms without pointer authentication. On
arm64e, however, calling a function can use two values from a
FunctionPointer: the pointer to the function and the discriminator. The
result was that on arm64e, swift_suspend_dispatch failed verification
because the discriminator value that was used in the call made by
swift_suspend_dispatch did not originate in that function.
Here, that problem is resolved by passing the discriminator to
swift_suspend_dispatch. Now, createAsyncDispatchFn creates a
FunctionPointer using not just the passed-in function pointer but also
the passed-in discriminator. The result is that swift_suspend_dispatch
no longer fails verification.
A partial apply of an async non-direct function entails storing a
pointer to the function's AsyncFunctionPointer into the thick context
using a specific (IGM.getOptions().PointerAuth.PartialApplyCapture)
ptrauth schema. Previously, the incorrect schema (derived from the
function type) was used to auth the ptr-to-AsyncFunctionPointer and then
to again sign the ptr-to-function. Here that error is corrected. Now,
the pointer-to-AsyncFunctionPointer is auth'd using that specific schema
and then the extracted function pointer is again signed again using it.
