mirror of
https://github.com/apple/swift.git
synced 2025-12-21 12:14:44 +01:00
82b7495bb1
An instruction is a deinit barrier whenever one of three component predicates is true for it. In the case of applies, it is true whenever one of those three predicates is true for any of the instructions in any of its callees; that fact is cached in the side-effect analysis of every function. If side-effect analysis or callee analysis is unavailable, in order to define each of those three component predicates on a `FullApplySite`/`EndApplyInst`/`AbortApplyInst`, it would be necessary to define them to conservatively return true: it isn't known whether any of the instructions in any of the callees were deinit barriers. Refactored the two versions of the deinit barrier predicate (namely `Instruction.isDeinitBarrier(_:) and `swift::mayBeDeinitBarrierNotConsideringSideEffects`) to handle `FullApplySite`/`EndApplyInst`/`AbortApplyInst`s specially first (to look up the callees' side-effect and to conservatively bail, respectively). Asserted that the three component predicates are not called with `FullApplySite`/`EndApplyInst`/`AbortApplyInst`s. Callers should instead use the `isDeinitBarrier` APIs. An alternative would be to conservatively return true from the three components. That seems more likely to result in direct calls to these member predicates, however, and at the moment at least there is no reason for such calls to exist. If some other caller besides the deinit-barrier predicates needs to call this function, side-effect analysis should be updated to cache these three properties separately at that point.