Doing so enables allocators to contain additional context for use by
allocation functions. Because the allocator is already passed to
_swift_coro_alloc, on the fast path (no allocator, popless) no
allocation function is used, and the allocator is passed in the
swiftcoro register, this is cheap.
This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
swift_coroFrameAlloc was introduced in the Swift 6.2 runtime. Give it
the appropriate availability in IRGen, so that it gets weak
availability when needed (per the deployment target). Then, only
create the stub function for calling into swift_coroFrameAlloc or
malloc (when the former isn't available) when we're back-deploying to
a runtime prior to Swift 6.2. This is a small code size/performance
win when allocating coroutine frames on Swift 6.2-or-newer platforms.
This has a side effect of fixing a bug in Embedded Swift, where the
swift_coroFrameAlloc was getting unconditionally set to have weak
external linkage despite behind defined in the same LLVM module
(because it comes from the standard library).
Fixes rdar://149695139 / issue #80947.
Delay the emission of SIL global variables that aren't externally
visible until they are actually used. This is the same lazy emission
approach that we use for a number of other entities, such as SIL
functions.
Part of rdar://158363967.
When targeting a platform that predates the introduction of isolated
deinit, make a narrow exception that allows main-actor-isolated deinit
to work through a special, inlineable entrypoint that is
back-deployed. This implementation
1. Calls into the real implementation when available, otherwise
2. Checks if we're on the main thread, destroying immediately when
we are, otherwise
3. Creates a new task on the main actor to handle destruction.
This implementation is less efficient than the implementation in the
runtime, but allows us to back-deploy this functionality as far back
as concurrency goes.
Fixes rdar://151029118.
If `LinkEntity::isTypeKind()` is true, `IRGenModule::getAddrOfLLVMVariable` assumes that we can safely call
`LinkEntity::getType()`, which does `reinterpret_cast` of `LinkEntity::Pointer` to `TypeBase *`. However, for SIL
differentiability witness, the pointer has `SILDifferentiabilityWitness *` type, which is not derived from `TypeBase`. So, such a cast is not allowed.
Just as with `ProtocolWitnessTableLazyAccessFunction` and `ProtocolWitnessTableLazyCacheVariable` link entity kinds (which are also type kinds), we should use `SecondaryPointer` instead of `Pointer` for storing payload here, while setting `Pointer` to `nullptr`.
Calling setupLLVMOptimizationRemarks overwrites the MainRemarkStreamer
in the LLVM context. This prevents LLVM from serializing the remark meta
information for the already emitted SIL remarks into the object file.
Without the meta information bitstream remarks don't work correctly.
Instead, emit SIL remarks and LLVM remarks to the same RemarkSerializer,
and keep the file stream alive until after CodeGen.
When creating a block, ensure that we correctly associate the DLL
Storage on the `_NSConcreteStackBlock` root object declaration based
upon whether we are generating code with `-static-libclosure` being
passed to the clang importer or not.
Expose the createStructType helper to clients of IRGenModule which want
to define types which won't ever be used elsewhere. This is just a
convenience--such clients could already have directly used the API on
llvm::Module directly.
Remove a static variable that caches pointer value from ASTContext that
will become invalid if the same process is re-used for compilation using
a second ASTContext. This configuration is used under
`-enable-deterministic-check` option for output detertiminism checking.
rdar://147438789
When it's available, use an open-coded allocator function that returns
an alloca without popping if the allocator is nullptr and otherwise
calls swift_coro_alloc. When it's not available, use the malloc
allocator in the synchronous context.
Correct the IRGen for the standard library. The thinko here assumed that the else case would be evaluated for the standard library build. We ended up incorrectly handling the well-known VWTs from the runtime when building the standard library.
This adjusts the runtime function declaration handling to track the
owning module for the well known functions. This allows us to ensure
that we are able to properly identify if the symbol should be imported
or not when building the shared libraries. This will require a
subsequent tweak to allow for checking for static library linkage to
ensure that we do not mark the symbol as DLLImport when doing static
linking.
The well known builtin and structural types are strongly defined in the
runtime which is compacted into the standard library. Given that the VWT
is defined in the runtime, it is not visible to the Swift compilation
process and as we do not provide a Swift definition, we would previously
compute the linkage as being module external (`dllimport` for shared
library builds). This formed incorrect references to these variables and
would require thunking to adjust the references.
One special case that we add here is the "any function" type
representation (`@escaping () -> ()`) as we do use the VWT for this type
in the standard library but do not consider it part of the well known
builtin or structural type enumeration.
These errors were previously being swallowed by the build system and
thus escaped from being fixed when the other cases of incorrect DLL
storage were.
Put AvailabilityRange into its own header with very few dependencies so that it
can be included freely in other headers that need to use it as a complete type.
NFC.
Remove `IRGenModule::useDllStorage()` as there is a standalone version
that is available and the necessary information is public from the
`IRGenModule` type. Additionally, avoid the wrapped `isStandardLibrary`
preferring to use the same method off of the public accessors. This
works towards removing some of the standard library special casing so
that it is possible to support both static and dynamic standard
libraries on Windows.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
As per #65930, the Clang importer's Clang instance may be configured with a different (higher) OS version than the compilation target itself in order to be able to load pre-compiled Clang modules that are aligned with the broader SDK, and match the SDK deployment target against which Swift modules are also built. Code-generation, however, must use the actual compilation target triple. This matches how Swift itself loads Swift module dependencies as well: dependency '.swiftinterface' files are type-checked against the availability epoch and code-generated against the actual compilation triple.
Resolves rdar://113712186
