Before deleting a load, simply rewrite its debug info to refer to the
loaded address:
%l = load %a
debug_value %l, loc0, scope0, var0
--->
debug_value %a, loc0, scope0, var0, expr op_deref
%l = load %a
Note that alloc_stack addresses do not require the addition of
op_deref because they are already special-cased in IRGen.
This will be called from salvageDebugInfo when it is supported by
optmizations. Until then, it is only called selectively at -Onone.
Instead bail when trying to deleted a dead closure or when performing the apply-of-partial_apply optimization.
TODO: In OSSA this should be solvable without the need of copies to temporaries.
Although nonescaping closures are representationally trivial pointers to their
on-stack context, it is useful to model them as borrowing their captures, which
allows for checking correct use of move-only values across the closure, and
lets us model the lifetime dependence between a closure and its captures without
an ad-hoc web of `mark_dependence` instructions.
During ownership elimination, We eliminate copy/destroy_value instructions and
end the partial_apply's lifetime with an explicit dealloc_stack as before,
for compatibility with existing IRGen and non-OSSA aware passes.
When salvaging debug info, it is not always permissible to create the
new debug info instruction at the same location as the old instruction:
the old instruction may occur after the end of the lifetime of the new
debug_value operand.
Rather than inserting dealloc_stacks at the end of blocks in the
dominance frontier of the alloc_stack, walk backward in the block to the
last user (if any) and insert after that (or at the beginning of the
block if not). If the transitive uses aren't understood, just insert at
the end of the blocks as before.
Previously, the dealloc_stacks created for the alloc_stacks used to pass
@in_guaranteed arguments to on_stack closures were created after the
users of the closure. When SILGen created these alloc_stacks in the
same block as the users, this happened to work. Now that
AddressLowering creates such alloc_stacks elsewhere, this approach
results in invalid SIL.
Here, the dealloc_stacks are instead at the end of each block in the
dominance frontier of the alloc_stack.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
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.
Andy some time ago already created the new API but didn't go through and update
the old occurences. I did that in this PR and then deprecated the old API. The
tree is clean, so I could just remove it, but I decided to be nicer to
downstream people by deprecating it first.
`salvageDebugInfo` is called during SIL Mem2Reg and could produce misleading debug info in the following case:
```
%a = alloc_stack $MyModel.TangentVector, var, name "self", argno 1, implicit, loc "debug2.swift":37:17 ...
...
store %b to %a : $*MyModel.TangentVector
```
Such SIL could be created as a result of inlining (where store comes from the inlined function).
Before this patch we'd end with `debug_value` instruction with variable information, but without or incorrect location.
This caused LLVM IR debug info verifier assertions when there might be another instruction with complete debug info (including location) for the same argument.
After this patch we always reuse it from destination alloca
Fixes#58660
Setup the API for use with SimplifyCFG first, so the OSSA RAUW utility
can be redesigned around it. The functionality is disabled because it
won't be testable until that's all in place.
Previously, the addArgumentToBranch only allowed one to add a single
additional argument to a branch. It then verified the argument count.
That is a problem if multiple arguments have to be added to arrive at
the correct argument count.
Specifically, that was a problem when running Mem2Reg on a lexical
alloc_stack, where three new phi arguments are added.
Here, the function name is changed to addArgumentsToBranch (plural
arguments) and the function accepts a SmallVector<SILValue> rather than
a single SILValue, allowing one to add all the arguments that are
necessary in order to verify that the resulting number of arguments is
correct.
To create OSSA terminator results, use:
- OwnershipForwardingTermInst::createResult(SILType ValueOwnershipKind)
- SwitchEnumInst::createDefaultResult()
Add support for passing trivial values to nontrivial forwarding
ownership. This effectively converts None to Guaranteed ownership.
This is essential for handling ".none" enums as trivial values while
extracting a nontrivial payload with switch_enum. This converts None
to Guaranteed ownership. Generates a copy if needed to convert back to
Owned ownership.
This patch replace all in-memory objects of DebugValueAddrInst with
DebugValueInst + op_deref, and duplicates logics that handles
DebugValueAddrInst with the latter. All related check in the tests
have been updated as well.
Note that this patch neither remove the DebugValueAddrInst class nor
remove `debug_value_addr` syntax in the test inputs.
In OSSA RLE for loops, in certain cases SSAUpdater will not create a new
SILPhiArgument to be used as the forwarding value. Based on dominator info
it may return the newly copied available value as the forwarding value.
This newly copied available value in the dominating predecessor
will have destroy values at leaking blocks.
Rename makeNewValueAvailable to makeValueAvailable and handle users so that only
additional required destroy_values are inserted.
We were using compiler-generated source location (i.e. line number
0) on `debug_value` instructions were emitted by salvage debug info.
But it turned out that IRGen will attach DW_AT_artificial on the
associated debug variables, which are hidden in debugger by default.
This patch prevent this issue by using the source location from the
just-deleted instruction for these `debug_value` instructions.
This indirectly triggered another bug where some of the LLVM
!DIExpression-s we generated are actually invalid -- more specifically,
the fragment inside is covering the whole debug variable. The reason it was
not previously caught is because LLVM verifier skips any debug variable
that is marked artificial, and all debug variables that have illegal fragment
are falling under this category. Thus, this patch also fixes this issue
by not generating the DW_OP_LLVM_fragment part if it's illegal.
OSSA rauw cleans up end of scope markers before rauw'ing.
This can lead to inadvertant deleting of end_lifetime, later
resulting in an ownership verifier error indicating a leak.
This PR stops treating end_lifetime scope ending like end_borrow/end_access.
SROA and Mem2Reg now can leverage DIExpression -- op_fragment, more
specifically -- to generate correct debug info for optimized SIL. Some
important highlights:
- The new swift::salvageDebugInfo, similar to llvm::salvageDebugInfo,
tries to restore / transfer debug info from a deleted instruction.
Currently I only implemented this for store instruction whose
destination is an alloc_stack value.
- Since we now have source-variable-specific SIL location inside a
`debug_value` instruction (and its friends), this patch teaches
SILCloner and SILInliner to remap the debug scope there in addition
to debug scope of the instruction.
- DCE now does not remove `debug_value` instruction whose associating
with a function argument SSA value that is not used elsewhere. Since
that SSA value will not disappear so we should keep the debug info.
Debug variables that are marked 'implicit' on its `debug_value`
instruction mean that they were generated by compiler. Optimizers are
free to remove them (if it becomes a dead code, for instance) even in
-Onone. Since they are barely used by users and keeping them might lead
to incorrect IRGen results.
