Similarly to how https://github.com/swiftlang/swift/pull/70564 configures 'ClangImporter's 'CodeGenerator' using Swift's compilation target triple, we must use the versioned version of the 'isWeakImported' query to determine linkage for imported Clang symbols.
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.
This ended up in creating a lot of Array functions, even if a program didn't use Array at all.
Now, only add specialization attributes if a function is already there.
Otherwise remember the attributes and add them to a function once it is created.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
inlining, generic/closure specialization, and devirtualization optimization passes.
SILFunction::canBeInlinedIntoCaller now exlicitly requires a caller's SerializedKind_t arg.
isAnySerialized() is added as a convenience function that checks if [serialized] or [serialized_for_pkg].
Resolves rdar://128704752
[serialized_for_package] if Package CMO is enabled. The latter kind
allows a function to be serialized even if it contains loadable types,
if Package CMO is enabled. Renamed IsSerialized_t as SerializedKind_t.
The tri-state serialization kind requires validating inlinability
depending on the serialization kinds of callee vs caller; e.g. if the
callee is [serialized_for_package], the caller must be _not_ [serialized].
Renamed `hasValidLinkageForFragileInline` as `canBeInlinedIntoCaller`
that takes in its caller's SerializedKind as an argument. Another argument
`assumeFragileCaller` is also added to ensure that the calle sites of
this function know the caller is serialized unless it's called for SIL
inlining optimization passes.
The [serialized_for_package] attribute is allowed for SIL function, global var,
v-table, and witness-table.
Resolves rdar://128406520
SILFunction::shouldBePreservedForDebugger checks if some optimizations
are enabled to decide whether a function should be preserved so its
accessible form the debugger or not. Some of these settings used to live
only in IRGenOptions making SILFunction depend on IRGenOptions.
package-wide resilience domain if Package CMO is enabled.
The purpose of the attribute includes:
- Indicates that certain types such as loadable types are
allowed in serialized functions in resiliently built module
if the optimization is enabled, which are otherwise disallowed.
- Used during SIL deserialization to determine whether such
functions are allowed.
- Used to determine if a callee can be inlined into a caller
that's serialized without package-cmo, e.g. with an explicit
annotation like @inlinable, where the callee was serialized
due to package-cmo.
Resolves rdar://127870822
At Onone, many types of functions (anything user written, compiler
generated setters and getters, etc), should be kept in the final
binary so they're accessible by the debugger.
rdar://126763340
module when package serialization is enabled, return maximal resilience expansion
in SILFunction::getResilienceExpansion(). This allows aggregate types to be generated
as loadable SIL types which otherwise are address-only in a serialized function.
During type lowering, opaque flag setting is also skipped if package serialization
is enabled.
Resolves rdar://127400743
* Add a new flag -experimental-package-cmo that requires -experimental-allow-non-resilient-access.
* Support serializing package decls for CMO in package if enabled.
* Only applies to default mode CMO.
* Unlike the existing CMO, package CMO can be built with -enable-library-evolution as package
modules are required to be built together in the same project.
* Create hasPublicOrPackageVisibility to opt in for package decls; needed for CMO, SILVerifier,
and other call sites that verify or determine codegen.
Resolves rdar://121976014
In embedded swift all de-serialized get public linkage because all the code is generated in the top-level module.
This change moves the point where we make de-serialized functions public to the end of the pipeline.
This allows dead function elimination to remove unused de-serialized functions.
For some stdlib functions (actually one: the Double initializer for a builtin integer) is essential, because codegen for embedded produces an unresolved symbol.
rdar://123772098
Ad-hoc requirements are now obsolete by making `remoteCall`,
`record{Argument, ReturnType}`, `decodeNextArgument` protocols
requirements and injecting witness tables for `SerializationRequirement`
conformances during IRGen.
Specifies that the optimizer and IRGen must not add runtime calls which are not in the function originally.
This attribute is set for functions with performance constraints or functions which are called from functions with performance.
To verify if a function may read from an indirect argument, don't use AliasAnalysis.
Instead use the CalleeCache to get the list of callees of an apply instruction.
Then use a simple call-back into the swift Function to check if a callee has any relevant memory effect set.
This avoids a dependency from SIL to the Optimizer.
It fixes a linker error when building some unit tests in debug.
To do this I used 8 spare bits in the pointers in Operand for the custom flags.
The reason I did this is just like one sometimes wants to iterate and use
sets/worklists with Nodes/Blocks, one often wants to do it with operands
especially in situations where one wants to know a using instruction and the
value on the instruction that was used.
When building complex projects, there may cases of static libraries
which expose `@inlinable` functions which reference functions from
dynamically linked dependencies. In such a case, we need to consider the
provenance of the `function_ref` when determining the DLL storage for
linkage. We would previously use the deserialised metadata on the
`SILFunction` as there are entities where the `DeclContext` may not be
deserialised. However, this leaves us in a state where we are unable to
determine the actual provenance correctly in some cases. By simply
accessing the parent module directly from the `SILFunction` we ensure
that we properly identify the origin of the function allowing us to
query the DLL storage property. This further allows us to remove the
extra storage required for whether the `SILFunction` is statically
linked.
We don't support generating code for ptrauth builtins with generic
inputs (or non-constant inputs). We rely on specialization/inlining for
such code to work.
After a recent commit (#68843 ) code in IRGen keeps internal unreferenced
functions alive for debugging purposes.
This is a problem for the generic functions in PtrAuth.swift using
ptrauth builtins.
Opt out of this new behavior by sprinkling some pixie dust.
Fixes debug swift standard library builds targeting arm64e.
rdar://117411740
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
Currently, when compiling with no optimizations on, we still delete
functions that are sometimes used in the debugger. For example, users
might want to call functions which are unused, or compiler generated
setters/getters.
rdar://101046198
Currently, when compiling with no optimizations on, we still delete
functions that are sometimes used in the debugger. For example, users
might want to call functions which are unused, or compiler generated
setters/getters.
rdar://101046198
