We've been building up this exponential explosion of task-creation
builtins because it's not currently possible to overload builtins.
As long as all of the operands are scalar, though, it's pretty easy
to peephole optional injections in IRGen, which means we can at
least just use a single builtin in SIL and then break it apart in
IRGen to decide which options to set.
I also eliminated the metadata argument, which can easily be recreated
from the substitutions. I also added proper verification for the builtin,
which required (1) getting `@Sendable` right more consistently and (2)
updating a bunch of tests checking for things that are not actually
valid, like passing a function that returns an Int directly.
The main change here is in IRGen which needs to be able to emit constant enum values.
Use `emitValueInjection` to create the enum constant.
Usually this method creates code in the current function.
But if all arguments to the enum are constant, the builder never has to emit an instruction.
Instead it can constant fold everything and just returns the final constant.
Also, create statically initialized let-globals as constant global (`constant` instead of `global`).
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.
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
Here, the following is implemented:
- Construction of SwiftContext struct with the fields needed for calling
functions.
- Allocating and deallocating these swift context via runtime calls
before calling async functions and after returning from them.
- Storing arguments (including bindings and the self parameter but not
including protocol fields for witness methods) and returns (both
direct and indirect).
- Calling async functions.
Additional things that still need to be done:
- protocol extension methods
- protocol witness methods
- storing yields
- partial applies
Use the generic type lowering algorithm described in
"docs/CallingConvention.rst#physical-lowering" to map from IRGen's explosion
type to the type expected by the ABI.
Change IRGen to use the swift calling convention (swiftcc) for native swift
functions.
Use the 'swiftself' attribute on self parameters and for closures contexts.
Use the 'swifterror' parameter for swift error parameters.
Change functions in the runtime that are called as native swift functions to use
the swift calling convention.
rdar://19978563
It's not worth burning more than three registers on a parameter, and doing so causes code size issues for large structs and enums. Make it so that values with more than three explosion members get passed indirectly, just like they get returned indirectly.
This time, modify emitPartialApplyForwarder not to attempt to 'tail' call the original function when indirect arguments get alloca'ed on the stack, which is UB, and don't use "byval", as suggested by John.
Swift SVN r29032
It's not worth burning more than three registers on a parameter, and doing so causes code size issues for large structs and enums. Make it so that values with more than three explosion members get passed indirectly, just like they get returned indirectly.
Swift SVN r29016
If a type has to be passed or returned resiliently, it
will necessarily be passed indirectly, which is already
represented in SILFunctionType. There is no need to
represent this as a separate channel of information.
NFC. Also fixes a problem where the signature cache
for ExtraData::Block was writing past the end of an
array (but into the storage for an adjacent array
which was fortunately never used).
ExtraData should also disappear as a concept, but we're
still relying on that for existential protocol witnesses.
Swift SVN r21548
it means that the argument should be passed as that
expanded sequence of types.
It turns out that LLVM makes an effort to automatically
break apart such arguments during CC lowering, but (1) it's
friendlier to break them apart ourselves and (2) it's
necessary to break them apart if we want to call inline
functions from the header.
Fixes rdar://17631440
Swift SVN r21420
Push LLVM attribute generation from expandAbstractCC into getFunctionSignature and CallEmission so that they can generate sret and/or byval attributes per-argument according to the calling convention. Copy our bogus rule for emitting sret returns (more than three elements in the explosion) and reuse it to pass large struct values as byvals rather than as explosions. This should be good enough to get both 'NSRect' and
'NSRange', 'NSSize' etc. to pass correctly to ObjC methods. Next step is to set the AbstractCC correctly for imported func decls so that standalone C functions follow the same bogus rule.
Swift SVN r3993
of a class is part of the class members section and is not
global to the entire class metadata. This is crucial for
correct operation of functions expecting a base-class
metadata object.
That gives us the correct foundation to implement an
optimization under which generic arguments that can be
inferred from the 'this' pointer need not actually be
separately passed. This has the important result of
making all class member functions with the same signature
up to abstraction actually have the same physical
signature.
Swift SVN r2936
Mangling is still a hack, pending a better type AST. Fixed
a bug where arguments passed indirectly were not being destroyed
by the callee (when passed by value). Changed some of the protocol
signatures to use the generic opaque pointer type, making the
types a bit more self-documenting in the IR.
Swift SVN r2274
exactly how the arguments are emitted. Introduce a new code path
which emits arguments from existing Explosions (possibly of the wrong
resilience level). Use that code path to implement getter/setter
code for MemberRefExpr l-values. This is just a checkpoint for the
latter two parts, but the ApplyExpr path is working correctly in the
new framework, which is worth a commit.
Swift SVN r1589
require Explosion.h. This is just to isolate the parts
of IR-generation that shouldn't have anything to do with
emitting code within functions.
Swift SVN r1039
very useful; it is much more interesting to divide r-value emission
into "to arguments" and "to memory" models. To that end, introduce a
new structure for holding an "exploded" r-value.
Swift SVN r1006
