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.
For two reasons:
* We also like to check for assert failures in release builds. Although this could be achieved with `precondition`, it's easy to forget about it and use `assert` instead.
* We need to see the error message in crashlogs of release builds. This is even not the case for `precondition`.
Also, re-export the "Basic" module in "SIL" so that the new assert implementation is also available in the Optimizer module (where all files import SIL).
So far, argument effects were printed in square brackets before the function name, e.g.
```
sil [escapes !%0.**, !%1, %1.c*.v** => %0.v**] @foo : $@convention(thin) (@guaranteed T) -> @out S {
bb0(%0 : $*S, %1 : @guaranteed $T):
...
```
As we are adding more argument effects, this becomes unreadable.
To make it more readable, print the effects after the opening curly brace, and print a separate line for each argument. E.g.
```
sil [ossa] @foo : $@convention(thin) (@guaranteed T) -> @out S {
[%0: noescape **]
[%1: noescape, escape c*.v** => %0.v**]
bb0(%0 : $*S, %1 : @guaranteed $T):
...
```
* add `DynamicFunctionRefInst` and `PreviousDynamicFunctionRefInst`
* add a common base class to all function-referencing instructions: `FunctionRefBaseInst`
* add `KeyPathInst`
* add `IndexAddrInst.base` and `IndexAddrInst.index` getters
* add `Instruction.visitReferencedFunctions` to visit all functions which are referenced by an instruction
It fixes the default reflection for bridged random access collections, which usually have a `bridged` stored property.
Conforming to this protocol displays the "real" children of a bridged random access collection and not just `bridged`.
While I was using the new AccessUtils for a new optimization pass I discovered some areas for improvements. Also I found some bugs.
Changes:
* AccessBase: remove the unhealthy redundancy between `kind` and `baseAddress` types. Now AccessBase is single enum with the relevant base objects/addresses as payloads.
* AccessBase: for `global`, store the `GlobalValue` and not a `global_address` instruction, which is more accurate (because there can be multiple `global_addr`s for a single global variable)
* AccessBase: drop the support for function argument "pointers". The `pointer` is now always a `pointer_to_address` instruction. This also simplifies `PointerIdentification`: either it finds a matching `address_to_pointer` or it bails.
* AccessBase: improve `func isDistinct(from:)`. There are more possibilities to prove that two access bases do not alias.
* AccessBase: replace `var isUniquelyIdentified` with `var hasKnownStorageKind` which is more useful for aliasing checking.
* AccessPath: fix `func isDistinct(from:)`. `SmallProjectionPath.matches` is the wrong way to check if two expression paths may overlap. Instead use the new `SmallProjectionPath.mayOverlap`.
* AccessStoragePathWalker: rename `getAccessStorage` -> `visitAccessStorageRoots` and let it return false if it's not a class/reference AccessBase.
* add tests for `AccessPath.isDistinct(from:)`
* "merge" the `Path` and `State` in WalkUtils into a single `WalkingPath`. This makes it simpler for clients to configure a path and additional state variables. EscapeInfo now defines `EscapePath` which includes the projection path and EscapeInfo's specific state variables.
* Make the `WalkerCache` part of the WalkUtils, so that not all clients have to re-implement it.
* Rename `walkDownResults` -> `walkDownAllResults` and `walkUpOperands` -> `walkUpAllOperands` and make these functions client configurable.
It needs to return nil in case the callee argument is not really applied by the ApplySite.
This fixes a crash in EscapeInfo when handling "escaping-to" effects:
If the callee operand of an apply instruction is a `partial_apply` of a `function_ref`, the callee-analysis looks through the `partial_apply` and we get the referenced function as a callee.
In this case there are less apply arguments than callee arguments, because the `partial_apply` already "applies" some of the callee arguments.
rdar://96830171
