executing unknown code
This means we have to claw back some performance by recognizing harmless
releases.
Such as releases on types we known don't call a deinit with unknown
side-effects.
rdar://143497196
rdar://143141695
i```
swift\lib\SILOptimizer\Mandatory\MoveOnlyAddressCheckerUtils.cpp(2981): warning C5030: attribute [[clang::fallthrough]] is not recognized
```
Replace the use of `clang::fallthrough` with `LLVM_FALLTHROUGH` which
properly uses the C++ standard spelling (`[[fallthrough]]`) depending on
the compiler version.
Removes a workaround previously added to handle types that were
overlooked during a serializability detection pass. Now that the
pass has been refactored with instruction visitor, we can replace
it with assert.
Resolves rdar://137711038
It was used in the old redundant-load- and redundant-store-elimination passes which were replaced by new implementations.
TypeExpansionAnalysis is not used anymore.
PredictableMemoryAccessOptimizations has become unmaintainable as-is.
RedundantLoadElimination does (almost) the same thing as PredictableMemoryAccessOptimizations.
It's not as powerful but good enough because PredictableMemoryAccessOptimizations is actually only needed for promoting integer values for mandatory constant propagation.
And most importantly: RedundantLoadElimination does not insert additional copies which was a big problem in PredictableMemoryAccessOptimizations.
Fixes rdar://142814676
It's sufficient just to have a struct with a kind and a value. There
aren't any cases where the payload's original type benefits from being
statically preserved--they're only ever obtained as `SILValue`s. Keep
the type safety by way of constructors.
This is necessary to fix a recent OSSA bug that breaks common occurrences on
mark_dependence [nonescaping]. Rather than reverting that change above, we make
forward progress toward implicit borrows scopes, as was the original intention.
In the near future, all InteriorPointer instructions will create an implicit
borrow scope. This means we have the option of not emitting extraneous
begin/end_borrow instructions around intructions like ref_element_addr,
open_existential, and project_box. After that, we can also migrate
GuaranteedForwarding instructions like tuple_extract and struct_extract.
Currently, types from @_implementationOnly modules can be serialized into client modules if their
defining modules are SDK or system modules.
However, @_implementationOnly is intended to hide types from external clients, and may cause
the type’s metadata (e.g., field offsets) to be stripped. If such types are serialized and later
accessed by a client module, it can lead to linker errors due to the missing metadata.
This PR prevents all types imported with @_implementationOnly from being serialized.
Resolves rdar://144181455
The code here determined the borrow scope of an InteriorPointerOperand use of a borrow using
`visitBaseValueScopeEndingUses`, but it does so after rewriting the operand, so the base
value would sometimes be incorrect leading to missing `end_borrows` in the rewritten code.
Fixes rdar://133333278.
The return pointer may point into the materialized base value, so if the base needs
materialization, ensure that materialization covers any futher projection of the
value.
To find if all the uses are within a guaranteed value, we should find all borrow introducers.
swift::findOwnershipReferenceAggregate looks only through forwarding operations with single operands.
For simplicity, continue using swift::findOwnershipReferenceAggregate, but return false when it does
not find a borrow introducer.
Starting in Swift 6.0, `package` access level and `@_spiOnly` attribute have been increasingly used in import statements.
However, existing import filtering prevented serialization of package APIs that included such decls, leading to a
significant drop in overall serialization. This PR removes these restrictive filters, and allows decls from SDK or system
modules to be included in serialization.
rdar://130788606
Otherwise, when one diagnoses code like the following:
```
Task {
{
use($0)
}(x)
}
```
One gets that $0 was captured instead of x. Unfortunately, since function
parameters do not have locations associated with them, we do not mark x
itself... instead, we mark the closure... which is unfortunate.
LICM in OSSA is enabled only for instructions involving trvial values.
begin_access/end_access is eligible for LICM in OSSA. However we need to
collect applies to check for conflicts.
rdar://143835241
In embedded mode CrossModuleOptimization must visit all vtable methods to make sure that no private/internal methods are serialized.
Fixes a compiler crash
rdar://143153941
