When an optimization updates borrowed-from instruction it might be necessary to remove the old enclosing values from the borrowed-from instructions.
An optimization might transform the SIL in a way that an existing enclosing value is not valid anymore.
Fixes a compiler crash:
rdar://142991910
Record a forwarding mark_dependence as a local access. This is necessary because
we now emit a mark_dependence for @out arguments, which will be the starting
point for diagnostics:
%out = alloc_stack
apply %f(%owned, %out) : $(Owner) -> @lifetime(borrow 0) @out View
%unused = mark_dependence [unresolved] %out on %owner
%dependentValue = load %out
This mark_dependence has no uses. Instead, it simply records the dependency of
the in-memory value on the owner. Consequently, simply walking the uses of
LifetimeDependence.dependentValue does fails to diagnose any escapes. Instead,
if the dependentValue is an address-type mark_dependence, treat it as a local
access to the address that it forwards. Then we find any reachable uses of that
local variable as a potential escape.
Fixes rdar://143040479
(Borrow diagnostics not triggered for @out return values)
Ignore marker instructions for the purpose of determining whether a store is a
full assignment:
%a = alloc_stack
%m = moveonlywrapper_to_copyable_addr %a
store %0 to [init] %m // <=== full assignemt
Unlike @in, treat @in_guaranteed like a caller-side dependence
scope because there is not need to look for the end of the lifetime in the
current function.
Completely fixes rdar://142847915 (Crash during lifetime checking
while building new swift standard library `Span`-related features)
For a lifetime dependent call that depends on a temporary store_borrow, the
generated mark_dependendence should be on the stored value, not the stack
location.
%temp = alloc_stack $AnyObject
%sb = store_borrow %arg to %temp
apply %10(%out, %sb)
mark_dependence [unresolved] %out on %arg
end_borrow %sb
Fixes rdar://142847915 (Crash during lifetime checking while
building new swift standard library `Span`-related features)
This encourages AccessPathWalker clients to handle enclosing mark_deps. In
some cases, it is necessary. The accessBaseWithScopes API now provides both
nested begin_access and mark_dependence.
Recognize dependence on the address of a trivial 'var' as an "access" dependence
instead of an "unknown" dependence. This allows the mark_dependence to be
resolved as "[nonescaping]".
This pass rewrites mark_depenendence to ignore "useless" borrow scopes. It was
also accidentally rewriting a dependence on a loaded value, which may redirect the
dependence to the access scope used to load that value. That access scope may be
narrower than the lifetime of the loaded value which could result in invalid
SIL. Do not rewrite this mark_dependence:
%access = begin_access [read] [unknown] %base
%load = load [trivial] %access
end_access %access
%adr = pointer_to_address
%md = mark_dependence [unresolved] %adr on %load
Fixes rdar://142424000 (Swift compiler crashes with Assertion failed
(isa<UnreachableInst>(block->getTerminator())))
* `users`: maps from a sequence of operands to a sequence of instructions
* `users(ofType:)` : as `users`, but filters users of a certain instruction type
* `Value.users`: = `Value.uses.users`
We can assume that memory is already initialized at the point of a 'yield'; a
yield use does not need to invalidate the single-initialization property for
temporary stack allocations.
Look through a call to the ConvertPointerToPointerArgument compiler intrinsic
just like it is a copy of the pointer. At the source level, that's all it is:
Treat this like a direct use of the argument 'p' rather than the result of the
invisible pointer conversion call:
func foo(_: UnsafeRawPointer)
func bar(p: UnsafePointer<T>) {
foo(p)
}
This is needed after running the SSAUpdater for an existing OSSA value, because the updater can
insert unnecessary phis in the middle of the original liverange which breaks up the original
liverange into smaller ones:
```
%1 = def_of_owned_value
%2 = begin_borrow %1
...
br bb2(%1)
bb2(%3 : @owned $T): // inserted by SSAUpdater
...
end_borrow %2 // use after end-of-lifetime!
destroy_value %3
```
It's not needed to run this utility if SSAUpdater is used to create a _new_ OSSA liverange.
It hoists `destroy_value` instructions without shrinking an object's lifetime.
This is done if it can be proved that another copy of a value (either in an SSA value or in memory) keeps the referenced object(s) alive until the original position of the `destroy_value`.
```
%1 = copy_value %0
...
last_use_of %0
// other instructions
destroy_value %0 // %1 is still alive here
```
->
```
%1 = copy_value %0
...
last_use_of %0
destroy_value %0
// other instructions
```
The benefit of this optimization is that it can enable copy-propagation by moving destroys above deinit barries and access scopes.
Just don't store the begin instruction.
This led to problem if the "begin" was not actually an instruction but a block argument.
Using the first instruction of that block is not correct in case the range ends immediately at the first instruction, e.g.
```
bb0(%0 : @owned $C):
destroy_value %0
```
Sometimes it can happen that a deinit function, which is imported from another module, has shared linkage.
In this case it is important to de-serialize the function body. Otherwise it would be illegal SIL.
Unfortunately I don't have a test case for this.
When replacing an `enum` - `unchecked_enum_data` pair and the enum's operand is another non-trivial enum which is constructed with a trivial payload, and this happens in different basic blocks, we need to insert a compensating `destroy_value`.
Fixes a verifier crash
rdar://139787167
For example:
```
%1 = begin_borrow %0
%2 = br bb1(%1, %1)
bb1(%3 : @reborrow @guaranteed, %4: @guaranteed):
// %4 is a guaranteed forwarding phi without any forwarding instructions between the begin_borrow and the incoming value.
```
Also improve the comments
