The relationship between the code in these two libraries was fundamentally circular, indicating that they should not have been split. With other changes that I'm making to remove circular dependencies from the CMake build graph I eventually uncovered that these two libraries were required to link each other circularly, but that had been hidden by other cycles in the build graph previously.
This invalidation kind is used when a compute-effects pass changes function effects.
Also, let optimization passes which don't change effects only invalidate the `FunctionBody` and not `Everything`.
The check to avoid infinite recursion in case of call graph cycles didn't work correctly.
It didn't result in crashes, because the function also has an additional max-depth check, but it could lead to exponential complexity in some cases.
Unfortunately I don't have a test case for this fix.
Previously, we would turn a key path literal like `\.foo` in function type
context into a double-wrapped closure like this:
```
foo(\.x) // before type checking
foo({ $kp$ in { $0[$kp$] } }(\.x)) // after type checking
```
in order to preserve the evaluation semantics of the key path literal. This
works but leads to some awkward raw SIL generated out of SILGen which misses
out on various SILGen peepholes and requires a fair number of passes to clean
up. The semantics can still be preserved with a single layer of closure, by
using a capture list:
```
foo({[$kp$ = \.x] in $0[$kp$] }) // after type checking
```
which generates better natural code out of SILGen, and is also (IMO) easier
to understand on human inspection.
Changing the AST representation did lead to a change in code generation that
interfered with the efficacy of CapturePropagation of key path literals; for
key path literals used as nonescaping closures, a mark_dependence of the
nonescaping function value on the key path was left behind, leaving the key
path object alive. The dependence is severed by the specialization done in
the pass, so update the pass to eliminate the dependence.
Compared to the previous patch, this version removes the attempt to have
the type-checked function expression carry the noescape-ness of its context,
and allows for coerceToType to introduce a function conversion instead, since
that FunctionConversionExpr is apparently load-bearing for default argument
generators.
For example:
```
public static var privateFunctionPointer: (Int) -> (Int) = { $0 }
```
Fixes a verifier crash and/or undefined symbol error
rdar://99493254
This is a follow-up of 1dfb3b1a2a.
We need to be more conservative about types as for functions, because types can also "produce" symbols, like direct field offsets, etc.
rdar://96953318
So far, the swift-frontend decided by itself if CMO can be enabled. This caused problems when used with an old driver, which doesn't consider CMO.
Now, the driver decides when to use default CMO by passing this flag to swift-frontend.
The main point of this change is to make sure that a shared function always has a body: both, in the optimizer pipeline and in the swiftmodule file.
This is important because the compiler always needs to emit code for a shared function. Shared functions cannot be referenced from outside the module.
In several corner cases we missed to maintain this invariant which resulted in unresolved-symbol linker errors.
As side-effect of this change we can drop the shared_external SIL linkage and the IsSerializable flag, which simplifies the serialization and linkage concept.
If we are emitting a TBD file, the TBD file only contains public symbols of this module.
But not public symbols of imported modules which are statically linked to the current binary.
This prevents referencing public symbols from other modules which could (potentially) linked statically.
Unfortunately there is no way to find out if another module is linked statically or dynamically, so we have to be conservative.
Fixes an unresolved-symbol linker error.
rdar://89364148
This optimizes keypath-closures, like
```
a.map { \.x }
```
It results in a significant performance improvement for such code patterns.
rdar://87968067
The "regular" CMO is done with the option `-cross-module-optimization`. It's good for performance but can increase code size.
Now, which this change CMO is also done if the option is not given, but in a very conservative way. Only very small functions are serialized and not additional type metadata is kept alive.
rdar://70082202
* rename the CrossModuleSerializationSetup pass to simply CrossModuleOptimization
* remove the CMO specific serializer pass. Instead run the CrossModuleSerializationSetup pass directly before the standard serializer pass.
* correctly handle shared functions (e.g. specializations)
* refactoring
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
Replace the dynamic initialization of trivial globals with statically initialized globals, even in -Onone.
This is required to be able to use global variables in performance-annotated functions.
Also, it's a small performance improvement for -Onone.
Referenced functions within the initializer of a SILGlobalVariable must be handled like referenced functions in other functions.
Fixes an assert crash when compiling with -cross-module-optimization
This was a relict from the -sil-serialize-all days. This linkage doesn't make any sense because a private function cannot be referenced from another module (or file, in case of non-wmo compilation).
Avoid an infinite specialization loop caused by repeated runs of the ClosureSpecializer and CapturePropagation.
CapturePropagation propagates constant function-literals.
Such function specializations can then be optimized again by the ClosureSpecializer and so on.
This happens if a closure argument is called _and_ referenced in another closure, which is passed to a recursive call. E.g.
func foo(_ c: @escaping () -> ()) {
c()
foo({ c() })
}
rdar://80752327
The check for implementationOnly imports was already done for types, but it was missing for functions.
Fixes a crash when implementationOnly-importing a C module.
https://bugs.swift.org/browse/SR-15048
rdar://81701218
Fix innumerable latent bugs with iterator invalidation and callback invocation.
Removes dead code earlier and chips away at all the redundant copies the compiler generates.
Refactor SILGen's ApplyOptions into an OptionSet, add a
DoesNotAwait flag to go with DoesNotThrow, and sink it
all down into SILInstruction.h.
Then, replace the isNonThrowing() flag in ApplyInst and
BeginApplyInst with getApplyOptions(), and plumb it
through to TryApplyInst as well.
Set the flag when SILGen emits a sync call to a reasync
function.
When set, this disables the SIL verifier check against
calling async functions from sync functions.
Finally, this allows us to add end-to-end tests for
rdar://problem/71098795.
We cannot replace a load from a global let-variable with a function_ref, if the referenced function would violate the resilience rules.
That means if a non-public function_ref would be inlined into a function which is serialized.
The main change is to rename DeadFunctionElimination -> DeadFunctionAndGlobalElimination, because the pass is now also doing dead-global elimination.
A second change is to remove the FunctionLivenessComputation base class. It’s not used anywhere else.
It makes sense to to this in a single pass, because there might be dead cycles for globals and functions, e.g. if a global references a function in its static initializer and the function references that global.
Another improvement: eliminate dead global-initializers. Before we had an explicit SIL representation of statically initialized globals, we had to keep them alive.
rdar://32956923
If we know that we have a FunctionRefInst (and not another variant of FunctionRefBaseInst), we know that getting the referenced function will not be null (in contrast to FunctionRefBaseInst::getReferencedFunctionOrNull).
NFC
No one has touched this pass in years and I am going to do a little work in it
to help with concurrency. So I am formatting the pass before I make further
changes.
All I did was I renamed CamelCase -> camelCase and git-clang-format the diff. I
used clangd to incrementally perform the renaming using some integration into my
editor.
If a function uses a type imported as implementationOnly (or similar), it cannot be serialized.
I added a new API in ModuleDecl (canBeUsedForCrossModuleOptimization), which performs this check.
rdar://72864719
If the specialized function has a re-abstracted (= converted from indirect to direct) resilient argument or return types, use an alternative mangling: "TB" instead of "Tg".
Resilient parameters/returns can be converted from indirect to direct if the specialization is created within the type's resilience domain, i.e. in its module (where the type is loadable).
In this case we need to generate a different mangled name for the specialized function to distinguish it from specializations in other modules, which cannot re-abstract this resilient type.
This fixes a miscompile resulting from ODR-linking specializations from different modules, which in fact have different function signatures.
https://bugs.swift.org/browse/SR-13900
rdar://71914016
This makes it easier to understand conceptually why a ValueOwnershipKind with
Any ownership is invalid and also allowed me to explicitly document the lattice
that relates ownership constraints/value ownership kinds.
to check for improperly nested '@_semantic' functions.
Add a missing @_semantics("array.init") in ArraySlice found by the
diagnostic.
Distinguish between array.init and array.init.empty.
Categorize the types of semantic functions by how they affect the
inliner and pass pipeline, and centralize this logic in
PerformanceInlinerUtils. The ultimate goal is to prevent inlining of
"Fundamental" @_semantics calls and @_effects calls until the late
pipeline where we can safely discard semantics. However, that requires
significant pipeline changes.
In the meantime, this change prevents the situation from getting worse
and makes the intention clear. However, it has no significant effect
on the pass pipeline and inliner.
