- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
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.
