[5.9] Fix SIL function side effects to handle unapplied escaping closures

[atrick]

Fixes rdar://113339972 DeadStoreElimination causes uninitialized closure context

Before this fix, the recently enabled function side effect implementation would return no side effects for a partial apply that is not applied in the same function. This resulted in DeadStoreElimination incorrectly eliminating the initialization of the closure context.

The fix is to model the effects of capturing the arguments for the closure context. The effects of running the closure body will be considered later, at the point that the closure is applied. Running the closure does, however, depend on the captured values to be valid. If the value being captured is addressible, then we need to model the effect of reading from that memory. In this case, the capture reads from a local stack slot:

%stack = alloc_stack $Klass
store %ref to %stack : $*Klass
%closure = partial_apply [callee_guaranteed] %f(%stack)
  : $@convention(thin) (@in_guaranteed Klass) -> ()

Later, when the closure is applied, we won't have any reference back to the original stack slot. The application may not even happen in a caller.

Note that, even if the closure will be applied in the current function, the side effects of the application are insufficient to cover the side effects of the capture. For example, the closure body itself may not read from an argument, but the context must still be valid in case it is copied or if the capture itself was not a bitwise-move.

As an optimization, we ignore the effect of captures for on-stack partial applies. Such captures are always either a bitwise-move or, more commonly, capture the source value by address. In these cases, the side effects of applying the closure are sufficient to cover the effects of the captures. And, if an on-stack closure is not invoked in the current function (or passed to a callee) then it will never be invoked, so the captures never have effects.

(cherry picked from commit 4ce6fcf) (cherry picked from commit 8a71844)

main PR: #67955

[atrick]

@swift-ci test

[eeckstein]

lgtm

[atrick]

@tbkka 5.9 candidate - potential miscompilation, although we only observed it on main