This instruction can be inserted by Onone optimizations as a replacement for deleted instructions to
ensure that it's possible to single step on its location.
* split the `PassContext` into multiple protocols and structs: `Context`, `MutatingContext`, `FunctionPassContext` and `SimplifyContext`
* change how instruction passes work: implement the `simplify` function in conformance to `SILCombineSimplifyable`
* add a mechanism to add a callback for inserted instructions
Replace the generic `List` with the (non-generic) `InstructionList` and `BasicBlockList`.
The `InstructionList` is now a bit different than the `BasicBlockList` because it supports that instructions are deleted while iterating over the list.
Also add a test pass which tests instruction modification while iteration.
We can ignore any memory writes in a program termination point, because it's not relevant for the caller.
But we need to consider memory reads, otherwise preceeding memory writes would be eliminated by dead-store-elimination in the caller.
E.g. String initialization for error strings which are printed by the program termination point.
Regarding ownership: a program termination point must not touch any reference counted objects.
Previously, to workaround an issue with ShrinkBorrowScope (where it
assumed a reasonable definition of isDeinitBarrier), a placeholder
version of the function was added. It is now removed by moving the
implementation of a version of that predicate back to C++.
This is consistent with `Type.isTrivial`.
Also, introduce corresponding properties in `Value`: `hasTrivialType` and `hasTrivialNonPointerType`, because
1. It's less to type than `Type.isTrivial(in: function)` because `Value` knows in which function it is.
2. It fixes the corner case where value is an `Undef`, which has not parent function.
Functions "are deinit barriers" (more pedantically, applies of functions
are deinit barriers) if any of their instructions are deinit barriers.
During side-effect analysis, when walking a function's instructions for
other global effects, also check for the deinit-barrier effect. If an
instruction is found to be a deinit barrier, mark the function's global
effects accordingly.
Add SILFunction::isDeinitBarrier to conveniently access the effects
computed during ComputeSideEffects.
Update the isBarrierApply predicate to iterate over the list of callees,
if complete, to check whether any is a deinit barrier. If none is, then
the apply is not a deinit barrier.
Added new C++-to-Swift callback for isDeinitBarrier.
And pass it CalleeAnalysis so it can depend on function effects. For
now, the argument is ignored. And, all callers just pass nullptr.
Promoted to API the mayAccessPointer component predicate of
isDeinitBarrier which needs to remain in C++. That predicate will also
depends on function effects. For that reason, it too is now passed a
BasicCalleeAnalysis and is moved into SILOptimizer.
Also, added more conservative versions of isDeinitBarrier and
maySynchronize which will never consider side-effects.
So far, function effects only included escape effects.
This change adds side-effects (but they are not computed, yet).
It also involves refactoring of the existing escape effects.
Also the SIL effect syntax changed a bit. Details are in docs/SIL.rst
* In `ApplySite`: `argumentOperands` and `isCalleeOperand`
* In `ArgumentConvention`: `isIndirect`, `isIndirectIn` and `isGuaranteed`
* In `Function`: `isDefinition`, `numParameterArguments`, `numArguments`, `getArgumentConvention`, `effectAttribute`
* In `Type`: `isFunction` and `isCalleeConsumedFunction`
* In `Instruction`: `hasUnspecifiedSideEffects`
* New bridged instructions: `EndApplyInst` and `AbortApplyInst`
* `LoadInst.ownership`
* `BeginAccessInst.isStatic`
* make the `Allocation` protocol a `SingleValueInstruction` (instead of `AnyObject`)
Let's lldb's `po` command not print any "internal" properties of the conforming type.
This is useful if the `description` already contains all the information of a type instance.
A projected value consists of the original value and a projection path.
For example, if the `value` is of type `struct S { var x: Int }` and `path` is `s0`, then the projected value represents field `x` of the original value.
Also, use ProjectedValue instead of AccessStoragePath.
