If target doesn't support musttail (e.g. WebAssembly), the function
passed to coro.end.async can return control back to the caller.
So the frontend should emit 'ret void' instead of unreachable after the
coro.end.async intrinsic call to allow such situation.
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
Rather than using group task options constructed from the Swift parts
of the _Concurrency library and passed through `createAsyncTask`'s
options, introduce a separate builtin that always takes a group. Move
the responsibility for creating the options structure into IRGen, so
we don't need to expose the TaskGroupTaskOptionRecord type in Swift.
Introduce a builtin `createAsyncTask` that maps to `swift_task_create`,
and use that for the non-group task creation operations based on the
task-creation flags. `swift_task_create` and the thin function version
`swift_task_create_f` go through the dynamically-replaceable
`swift_task_create_common`, where all of the task creation logic is
present.
While here, move copying of task locals and the initial scheduling of
the task into `swift_task_create_common`, enabling by separate flags.
introduce new options parameter to all task spawning
[Concurrency] ABI for asynclet start to accept options
[Concurrency] fix unittest usages of changed task creation ABI
[Concurrency] introduce constants for parameter indexes in ownership
[Concurrency] fix test/SILOptimizer/closure_lifetime_fixup_concurrency.swift
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.
* Add explicit calling convention on builtin GetCurrentTask
This builtin function emits a call of swift_task_getCurrent, and user
code can declare the same name function with slightly different
signature at LLVM level (data size should be same) using @_silgen_name.
In that case, IRGen insert cast inst to cast the function to the
expected signature. But this cast inst drops calling convention info, so
call inst was emitted without swiftcc.
This patch changed to emit a call of swift_task_getCurrent with the
explicit calling convention.
* Add test case to ensure builtin function cc when conflict
The address of the function to be called when generating code to invoke
the function associated with FunctionPointer which is produced via
direct reference is by definition statically known; it is neither necessary
nor desireable to load this address out of the AsyncFunctionPointer
corresponding to the function.
Here, that spurious additional work is skipped. The approach is to add
a second value to the FunctionPointer struct. For FunctionPointers
whose kind is AsyncFunctionPointer, this value is either null or else
the address of the corresponding function.
rdar://71376092
Previously, AsyncFunctionPointer constants were signed as code. That
was incorrect considering that these constants are in fact data. Here,
that is fixed.
rdar://76118522
The immediate desire is to minimize the set of ABI dependencies
on the layout of an ExecutorRef. In addition to that, however,
I wanted to generally reduce the code size impact of an unsafe
continuation since it now requires accessing thread-local state,
and I wanted resumption to not have to create unnecessary type
metadata for the value type just to do the initialization.
Therefore, I've introduced a swift_continuation_init function
which handles the default initialization of a continuation
and returns a reference to the current task. I've also moved
the initialization of the normal continuation result into the
caller (out of the runtime), and I've moved the resumption-side
cmpxchg into the runtime (and prior to the task being enqueued).
