The lower type of the definition might be an opaque type while a call to
the same function in the same resilience domain might look through to an
underlying type.
rdar://101780666
This should be computed by SignatureExpansion in a more correct way.
The code here seems suspiciously off in the case we have both a direct
return result and one indirect return result.
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`.
If the IR representation of a C++ function takes an `SRet` parameter instead of a return value, Swift needs to wrap the corresponding argument with `sret(...)` on call site.
This fixes SILOptimizer crashes on arm64.
rdar://92963081
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.
`PointerType::getElementType` has been removed entirely as part of the
opaque pointers migration. Update to `getPointerElementType` for now
until we've also migrated.
Thanks to exclusivity checking, inout arguments can be marked noalias.
In the fullness of time, this should be applied in general.
As an incremental step towards marking all such arguments noalias, start
by marking inout arguments of pointer type noalias. Take this
conservative step rather than always applying the attribute to ward
against issues with LLVM's alias analysis.
rdar://76540030
Avoid a reabstraction thunk every time an async let entry point is emitted,
by setting the context abstraction level while we emit the implicit closure.
Adjust some surrounding logic that breaks when we do this:
- When lowering a non-throwing function type against a throwing abstraction
pattern, include the error type in the lowered substituted type. Async
throwing and nonthrowing functions would require another thunk to convert
away the throwingness of the async context, which would defeat the purpose.
- Adjust the code in IRGen that pads the initial context size for `async let`
entry points so that it works when the entry point has not yet emitted, by
marking the async function pointer to be padded later if it isn't defined
yet.
On some Harvard architectures like WebAssembly that allow sliding code
and data address space offsets independently, it's impossible to make
direct relative reference to code from data because the relative offset
between them is not representable.
Use absolute function references instead of relative ones on such targets.
We fixed a bug in the concurrency runtime (rdar://problem/90357994) that would
lead to memory corruption when a new `async let` child task tried to use the
last 16 bytes of the preallocated slab from its parent to seed its own task
allocator. To work around this bug in older OSes that shipped with the bug,
artificially pad the async coroutine context size for any async functions
used as an `async let` entry point, which will prevent the runtime from
going down the path of trying to use the preallocated storage at all.
rdar://90506708
* [cxx-interop] fix std::string::push_back by fixing mapping between clang/swift self/this type for cxx methods
* cleanup
* Fix unit test
* XFail test: operators/member-inline on linux-android
* add `C++` in expandExternalSignatureTypes comment
* Fix rebase
* Fix mapping issue in externalizeArguments
* Improve cxx_interop_ir test regex
Generated code has never actually initialized this field, so we
might as well remove it. Doing so mostly doesn't impact the ABI
since we don't store anything for arguments or results in the
context as part of the normal call sequence. We do need to adjust
some of the hard-coded contexts, however, such as continuation
contexts and the statically-sized context for special runtime
async functions.
In the "next" branch, set_size has been made protected. Instead, users
can use resize_for_overwrite, optionally followed by truncate, to
handle the same use cases more safely.
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.
