Usually there _must_ be a read from a consuming in-argument, because the function has to consume the argument.
But in the special case if all control paths end up in an `unreachable`, the consuming read might have been dead-code eliminated.
Therefore make sure to add the read-effect in any case. Otherwise it can result in memory lifetime failures at a call site.
fixes a memory lifetime failure
rdar://134881045
Do this even if the function then contains references to other functions with wrong linkage. Instead fix the linkage later.
Fixes a false error in embedded swift.
rdar://134352676
Make SILLInkage available in SIL as `SIL.Linkage`.
Also, rename the misleading Function and GlobalVariable ABI `isAvailableExternally` to `isDefinedExternally`
In lazy typechecking mode, errors in the program may only be discovered during
SILGen, which can leave the SIL in a bad state for subsequent stages of
compilation. If errors were detected, skip SIL verification and optimization to
prevent knock-on failures.
Partially reverts https://github.com/swiftlang/swift/pull/75428, which included
a more targeted fix for one of the possible knock-on effects of bad SIL coming
out of SILGen.
Resolves rdar://132107752.
The main changes are:
*) Rewrite everything in swift. So far, parts of memory-behavior analysis were already implemented in swift. Now everything is done in swift and lives in `AliasAnalysis.swift`. This is a big code simplification.
*) Support many more instructions in the memory-behavior analysis - especially OSSA instructions, like `begin_borrow`, `end_borrow`, `store_borrow`, `load_borrow`. The computation of end_borrow effects is now much more precise. Also, partial_apply is now handled more precisely.
*) Simplify and reduce type-based alias analysis (TBAA). The complexity of the old TBAA comes from old days where the language and SIL didn't have strict aliasing and exclusivity rules (e.g. for inout arguments). Now TBAA is only needed for code using unsafe pointers. The new TBAA handles this - and not more. Note that TBAA for classes is already done in `AccessBase.isDistinct`.
*) Handle aliasing in `begin_access [modify]` scopes. We already supported truly immutable scopes like `begin_access [read]` or `ref_element_addr [immutable]`. For `begin_access [modify]` we know that there are no other reads or writes to the access-address within the scope.
*) Don't cache memory-behavior results. It turned out that the hit-miss rate was pretty bad (~ 1:7). The overhead of the cache lookup took as long as recomputing the memory behavior.
It's dangerous to continue walking over an `unchecked_addr_cast` which casts between two different types.
We can only do this if the result is known to be the end of the walk, i.e. the cast result is not used in a relevant way.
We need to compare the not lowered types, because function types may differ in their original version but are equal in the lowered version, e.g.
```
((Int, Int) -> ())
(((Int, Int)) -> ())
```
Fixes a miscompile
Invalid types are not considered Escapable. This makes it difficult to make any
assumptions about nonescapable types.
Fixes rdar://132348528 (Fix LifetimeDependenceDiagnostics to handle invalid SIL types)
These projections don't have access scopes, so the utility was treating them
like escapes.
Fixes: rdar://131499478 (Difficulties composing non-escapable types)
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
by -enable-experimental-feature NonescapableTypes
on the Windows platform
These passes do nothing unless the above feature flag is enabled, so
the only reason to run the pass is to exercise SwiftCompilerSources
and catch invalid SIL.
These passes rely on fundamental SwiftCompilerSources abstractions
which have not yet been tested outside of the passes. They don't yet
handle all SIL patterns, and SIL continues to evolve. We would like to
can these issues quickly as we hit them, but only if we have a way of
reproducing the failure. Currently, we don't have a way of reproducing
Windows-arm64 failures.
Workaround for:
rdar://128434000 ([nonescapable] [LifetimeDependenceInsertion]
Package resolution fails with arm64 Windows toolchain)
